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Sobre o livro 


Público-alvo 


Esta obra destina-se a estudantes e profissionais de 
desenvolvimento de software, principalmente para a plataforma 
Java. Profissionais que trabalham exclusivamente criando testes 
também são público para este livro pois o Spock também permite 
criar testes para REST APIs. 


Pré-requisitos 


Para melhor acompanhar o conteúdo desta obra, são necessárias 
noções intermediárias de programação com a plataforma Java, tais 
como: configuração do ambiente, orientação a objetos, coleções e 
tratamento de exceções. 


Esta obra contém capítulos sobre testes para REST APIs, Android, 
Spring Boot e Spring MVC. Tais capítulos são destinados a 
profissionais com o mínimo de conhecimento sobre essas 
tecnologias. 


Conceitos básicos sobre testes de software não são necessários 
pois são revisados em vários tópicos do livro. 


Caso o leitor tenha pouco ou nenhum conhecimento sobre a 
linguagem Groovy, pode recorrer ao Apêndice A - Guia de Groovy 
para desenvolvedores Java. 


A versão do Spock abordada neste livro foi a 1.1-groovy-2.4. 
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Prefácio 


Por Prof. Dr. Eduardo Martins Guerra* 


Há cerca de 20 anos, começava um movimento no mundo da 
engenharia de software, que contestava a forma como as coisas 
estavam sendo feitas e propunha novos valores. Surgiam o que 
chamamos hoje de métodos ágeis! 


Todos os princípios e técnicas do desenvolvimento ágil são 
baseados em uma premissa: o código existente deve ser fácil de ser 
modificado. Porém, isso não vem de graça! É necessária muita 
disciplina nas práticas utilizadas para que isso realmente seja uma 
realidade. Além de ser preciso cuidado constante para manter o 
código limpo e desacoplado, os testes automatizados também 
possuem um importante papel nessa questão. 


A presença de testes automatizados é importante para dar 
segurança em qualquer modificação do código. Seja para refatorá- 
lo, buscando frequentemente mantê-lo desacoplado, simples e 
legível, seja para inserir novas funcionalidades, os testes permitem 
uma detecção mais rápida quando algum comportamento anterior é 
quebrado. São esses testes que ajudam a manter baixo o custo de 
mudança, o que é fundamental, por exemplo, para viabilizar 
iterações curtas e com entregas frequentes. 


Porém, a princípio muita gente não se dá conta de que testar não é 
nada fácil! Principalmente quando estamos falando de testes 
automatizados. Um software interage com diversos recursos dentro 
de seu ecossistema e provê diferentes tipos de interface para a 
execução de suas funcionalidades. São questões técnicas como: 
mapeamento de classes para o banco de dados, acesso a serviços 
por REST APIs ou mesmo dependências de sistemas externos que 
precisam ser simulados. 


Ter que lidar com essas questões nos testes faz muita gente travar! 
Para superar essas dificuldades, é importante conhecer uma 


ferramenta adequada juntamente com as técnicas de testes. É por 
isso que esse livro que você tem em mãos a respeito do Spock 
framework contém um conhecimento muito valioso! Além de ensinar 
a utilizar as funcionalidades desse framework, ele ainda apresenta 
as técnicas de teste, juntamente com exemplos didáticos e focados 
em problemas do mundo real para tecnologias que são padrão de 
mercado. 


Conheci o Yoshi quando eu era editor-chefe da revista MundoJava, 
época em que ele sempre entrava em contato para propor artigos 
com temas atuais e extremamente relevantes para o mercado. Seus 
artigos eram sempre muito apreciados pela equipe técnica da 
revista e pelos nossos leitores devido à didática e à clareza com as 
quais apresentava os temas. Neste livro, ele acertou em cheio em 
uma temática na qual muita gente no mercado ainda precisa 
amadurecer. Tenho certeza de que a aplicação dos conceitos deste 
livro pode ser decisiva para o sucesso de muitos projetos! 


Bora testar, galera! 


* Eduardo Martins Guerra é pesquisador do INPE. Foi professor no 
ITA, onde concluiu sua graduação, mestrado e doutorado. Suas 
pesquisas focam no design, arquitetura e teste de software. Foi 
editor-chefe da revista MundoJava por vários anos. É autor/co-autor 
de vários livros na área de computação. 


Comentários sobre o livro 


"Escrito de forma bem clara e didática, este livro não se restringe a 
apenas ensinar como utilizar o framework Spock, mas também 
apresenta de forma bem abrangente os principais conceitos 
relacionados a testes de software, bem como um comparativo entre 
as ferramentas de testes existentes no mercado. O uso do Spock é 
exemplificado em diversas plataformas e frameworks, incluindo 
Spring, REST APIs e Android. Leitura imprescindível para todos os 
que prezam pela qualidade de seu software.” 


Célia Taniwaki. Professora na faculdade Bandtec. Mestra em Eng. 
Elétrica pela USP e Especialista em Eng. Elétrica pela Mei 
University do Japão. Foi analista/desenvolvedora na Itautec por 13 
anos. Já traduziu vários livros e revistas de computação. 


"Este livro do Yoshi é um ensaio tecnológico sobre testes de 
software. De forma equilibrada explora conceitos importantes sobre 
testes de softwares e de várias ferramentas de testes relevantes no 
mercado. Todo desenvolvedor deve conhecer este livro, pois é rico 
de exemplos e explica, detalhadamente, como configurar e aplicar 
as ferramentas nas principais IDEs e linguagens de programação da 
plataforma Java.” 


Daniel Couto Gatti. Diretor da Faculdade de Ciências Exatas e 
Tecnologia da PUC-SP e professor na faculdade Bandtec. Doutor 
em Educação Matemática e Mestre em Comunicação e Semiótica 
pela PUC-SP. É autor de vários livros na área de computação. 


"Este livro que você tem em mãos a respeito do Spock framework 
contém um conhecimento muito valioso! Além de ensinar a utilizar 
as funcionalidades desse framework, ele ainda apresenta as 
técnicas de teste, juntamente com exemplos didáticos e focados em 
problemas do mundo real para tecnologias que são padrão de 
mercado. Neste livro, o Yoshi acertou em cheio em uma temática na 
qual muita gente no mercado ainda precisa amadurecer. Tenho 


certeza de que a aplicação dos conceitos deste livro pode ser 
decisiva para o sucesso de muitos projetos" 


Eduardo Martins Guerra. Pesquisador no INPE. Doutor e Mestre 
em Eng. Eletrônica e Computação pelo ITA, onde também foi 
professor. Foi editor-chefe e articulista da revista MundoJava. É 
autor de vários livros na área de computação. 


"Fazia muito tempo que esperava por um livro como este do 
Yoshiriro: é relevante, enriquece o leitor e vai além de um mero 
tutorial de Spock”. Aprendi coisas novas durante a sua leitura, 
coisas que vão além da documentação oficial. Se você quer 
entender como o Spock funciona - um framework que vejo muita 
gente aprender por aí dando murro em ponta de faca - creio que o 
livro é este. É bem fundamentado, bem escrito, didático e direto ao 
ponto. Você aprenderá não só como o Spock funciona, mas também 
algumas coisas a mais que valerão a pena no final. É o manual que 
faltava para o framework: que bom que foi escrito aqui no Brasil e 
em português para que torne essa poderosa ferramenta mais 
acessível.” 


Henrique Lobo Weissmann (Kico). Sócio-fundador da itexto, 
empresa de desenvolvimento de sistemas. Referência nacional em 
Spring e Groovy/Grails, sendo autor de livros sobre essas 
tecnologias e criador da comunidade Grails Brasil. 


"Tive o privilégio de acompanhar parte do processo de formação do 
José Yoshiriro, como professor na graduação. Ele sempre foi muito 
entusiasmado com a Tecnologia. Mas, além disso, tinha desde cedo 
muito forte o sentido da organização e da estruturação de ideias. 
Desta forma, é capaz de expressar conceitos Spring e complexos de 
maneira que as pessoas possam compreender facilmente. Ao ler 
este livro e conversar com o Yoshiriro, fico muito feliz em ver o 
quanto ele foi capaz de progredir ainda mais nestas habilidades com 
o passar do tempo. A destacar: a forma como foram escolhidos e 
colocados para o leitor os diversos tipos de teste, que formam a 
linha de base das aplicações do livro. Com certeza, esta obra é uma 


leitura que, além de levar ao conhecimento técnico específico, é 
inspiradora no sentido de formas inovadoras de comunicação.” 


Manoel José dos Santos Sena. Diretor Executivo do Mundo Digital 
Interativo - MDI e professor na faculdade FACI Wyden. Mestre em 
Concepção Mecânica e Doutor em Eng. Mecânica pela Université 
Joseph Fourier - Grenoble |, UJF da França. 


"O livro está muito bem escrito e gostei muito da forma como o 
conhecimento é construído: Saindo do básico, ensinando como 
configurar o ambiente, até chegar a testes com RESTful APIs. 
Mesmo sem conhecer Groovy, fui capaz de entender o 
funcionamento dos testes. O Apêndice A está muito bom e foi o 
suficiente para um desenvolvedor .NET entender o básico de 
Groovy." 


Paul Marques. Programa desde 2015 e atualmente é 
desenvolvedor na Coddera, onde trabalha com web services, 
sistemas Web e desktop e automação de sistemas. É tecnólogo em 
Análise e Desenvolvimento de Sistemas pela faculdade Bandtec. 


"De maneira muito intuitiva, apresenta uma disciplina fundamental 
para todo desenvolvedor de software. Esclarece aos mais 
apressados e dá as ferramentas para quem quer mais profundidade. 
Foca nos benefícios de usar a ferramenta de acordo com o 
problema e torna praticamente transparente a apresentação do uso 
de uma linguagem de programação não tão comum no Brasil, mas 
de adoção extremamente simples em qualquer aplicação Java. 
Percebe o tamanho do desafio cumprido na proposta desse livro?! 
Fico muito contente em poder contar com esse nível de material em 
português e ver a didática do Yoshiriro agora materializada além dos 
limites da sala de aula e projetos em que contribui. E que venham 
os próximos" 


Victor Franzonatto. Engenheiro de software sênior no Mercado 
Livre. Trabalha com desenvolvimento de software desde 2006. Já 


liderou projetos em empresas como IBM, Porto Seguro e BrasilPrev. 
Já publicou e traduziu vários artigos sobre tecnologia. 


CAPÍTULO 1 
Por que usar Spock framework? 


O Spock framework é uma ferramenta muito poderosa, que pode ser 
a grande aliada de sua equipe na construção mais rápida e simples 
de testes melhores e menos verbosos. Ela é uma ferramenta 
completa que dispensa a configuração de bibliotecas adicionais para 
implementação da maioria dos tipos testes automatizados. Dentre 
as funcionalidades que tornam o Spock tão completo, algumas que 
ganharam destaque nesta obra são: criação de simples testes 
unitários; uso de Mocks; o sensacional recurso de Data-Driven 
Testing; criação de testes unitários para Android, de integração para 
Spring e funcionais para REST APIs. 


Neste primeiro capítulo, veremos os principais motivos que tornam 
relevante a adoção do Spock framework na criação de testes 
automatizados. A própria importância da criação desses testes será 
revisada e reforçada. Um breve histórico do Spock e informações 
sobre a adoção serão abordados para demonstrar quão consolidada 
essa ferramenta está. 


1.1 Por que criar testes automatizados? 


A seguir, vejamos os principais motivos que demonstram a 
importância da criação de testes automatizados em um projeto de 
software. 


Porque qualidade sem testes é pura sorte 


O termo "teste" denota qualidade em qualquer área de 
conhecimento humano. Exemplos: governos só liberam a 
comercialização de medicamentos que foram devidamente 


testados. Você usaria um medicamento sabendo que não foi 
devidamente testado? Novos modelos de carros só começam a ser 
fabricados e vendidos após vários testes. Você dirigiria um carro 
sabendo que não foi suficientemente testado? Não poderia ser 
diferente com software: para a criação de um programa de 
qualidade, é preciso submetê-lo a quantos testes forem 
necessários. 


Porque testes manuais têm sua importância, mas os 
automatizados são indispensáveis 


Testes manuais, ou seja, executados integralmente por usuários 
humanos, possuem sua importância. Avaliações sobre usabilidade, 
aparência da interface, disposição e tamanho de elementos gráficos, 
dentre outros de natureza subjetiva, ainda são feitas melhor por 
pessoas. Supondo situações de pouco tempo, pouco orçamento e 
pouco conhecimento técnico da parte da equipe de 
desenvolvimento, os testes manuais seriam a melhor, senão única, 
alternativa. Por fim, quando não se tem acesso ao código do 
sistema, dependendo da sua natureza, a única forma de testar é 
manualmente (caso de alguns aplicativos nativos para Windows, por 
exemplo). 


Testes automatizados são pequenos programas criados por 
programadores para testar outros programas. Uma vez que não 
é um humano quem os executa, alguns benefícios imediatos são: 


e Velocidade infinitamente superior na execução dos testes; 

e Chances de erro no resultado do teste quase nulas; 

e Como são programas, ou seja, possuem um código-fonte, 
servem como evidência de que foram feitos testes; 

e As evidências dos resultados dos testes são geradas 
automaticamente; 

e Podem simular situações impossíveis para humanos, como 
milhões de execuções simultâneas, ou testes com valores 
aleatórios, por exemplo; 


e Todos os testes programados serão executados. Assim, não 
ocorre a omissão ou execução incorreta de alguns testes por 
cansaço, ansiedade, preguiça, má-fé etc.; 

e Podem ser reexecutados sempre que necessário. Isso é 
muito útil para saber se mudanças em uma parte código-fonte 
do projeto não tiveram algum efeito colateral inesperado em 
outra parte. 


Outro benefício interessante dos testes automatizados é que, 
durante o processo de criação deles, podem-se encontrar 
problemas de design no código testado, tais como excesso de 
métodos estáticos, alto acoplamento, baixa coesão etc. Um código 
difícil de ser testado é, provavelmente, um código que precisa ser 
refatorado. 


1.2 Testes que podemos criar com Spock 


O Spock framework é uma ferramenta que permite a criação de 
alguns tipos de testes automatizados, que são: 


Unitários (ou de unidade) 


Testes isolados para pequenas partes de um programa. 
Normalmente, cria-se uma classe de teste unitário para cada classe 
do projeto. Fazendo uma analogia com a fabricação de um carro, 
seria como testar, isoladamente, cada pequena peça que compõe o 
veículo. 


De integração 


Usado para testar a integração entre duas ou mais partes do 
programa ou a integração de uma parte do programa a um elemento 
externo (banco de dados, REST API etc). É um complemento aos 
testes unitários, pois uma parte que funciona perfeitamente sozinha 
não terá, necessariamente, um funcionamento perfeito em conjunto 


com outra(s). Na analogia com a fabricação de um carro, seria como 
testar a integração entre todas as peças que compõem o câmbio de 
um carro, ou seja, testar o câmbio montado. 


Funcionais (ou de sistema) 


Teste que valida o comportamento final, ou seja, se as saídas do 
sistema estão funcionando conforme o esperado. Exemplos: 


e Se o sistema em questão for um website, um teste poderia ser 
sobre uma de suas páginas HTML. 

e Se o sistema for uma REST API, um teste poderia ser sobre um 
de seus endpoints. 


Fazendo uma analogia com a fabricação de um carro, seria como 
testar um exemplar montado em situações como: como ele se 
comporta nas curvas conforme o esperado? Seu consumo de 
combustível na cidade é o esperado? O tempo e distância levados 
para parar estando a 40 km/h são os esperados? 


No caso dos testes unitários e de integração, o Spock permite 
criar testes para projetos que usam qualquer linguagem da 
plataforma Java. Quanto a testes funcionais, é possível criar 
testes para REST APIs e para websites. 


No livro da Casa do Código Testes automatizados de software: Um 
guia prático, de Maurício Aniche, os conceitos e a importância dos 
testes automatizados de software são mais profundamente 
detalhados. 


1.3 Por que usar Spock para projetos Java se 
temos JUnit, TestNG, Mockito etc.? 


Existem várias bibliotecas de teste para Java, como a JUnit 
(considerada a padrão de mercado) e a TestNG. Elas permitem criar 


os mesmos tipos de testes que o Spock. Por que então usar mais 
uma? A seguir, OS 7 principais motivos para adotar essa ferramenta. 


Spock não é mais uma ferramenta. É uma por todas. 


O primeiro motivo é que o Spock é um framework completo para a 
escrita de testes para o qual se propõe. Ele funciona out of the box, 
ou seja, basta configurá-lo em seu projeto, que já poderá criar 
praticamente todo tipo de teste unitário, de integração ou funcional, 
não precisando de mais dúzias de outras bibliotecas de testes. Até a 
criação de Mocks e Stubs pode ser feita sem a inclusão de 
bibliotecas como Mockito e PowerMock. Uma interessante 
consequência disso é que basta ter em mãos um livro e/ou ler 
apenas uma documentação oficial. 


Groovy em vez de Java: mais testes com menos código 


Spock usa como linguagem de programação a Groovy, que é bem 
menos verbosa que Java, permitindo que muitas operações comuns 
do cotidiano como iterações, criação de Mocks, manipulação de 
coleções, acesso a métodos privados (logo, possibilidade de testá- 
los) e conversões de tipos sejam feitas de forma bem menos 
burocrática (vide o Apêndice A - Guia de Groovy para 
desenvolvedores Java). 


Maven, Gradle, SBT e plugins das IDEs completas são 100% 
compatíveis 


A execução de testes automatizados escritos em Spock é realizada 
automaticamente no processo de build do Maven, do Gradle e do 
SBT e, com a funcionalidade de executar um ou mais arquivos de 
testes das IDEs Eclipse, IntelliJ e Netbeans, executa normalmente 
os testes criados com Spock. Isso porque os testes são 
interpretados por essas ferramentas como testes escritos em JUnit. 


Testes que falham indicam melhor por que falham 


Os testes que falham em Spock possuem uma descrição bem mais 
completa e assertiva do motivo da falha, evitando que se executem 
as classes de testes em modo Debug para, por exemplo, achar o 
que ocasionou UM NullPointerException OU com quantos elementos 
uma lista chegou ao final do teste. No capítulo 3. Primeiros testes 
automatizados com Spock é demonstrado esse comportamento. 


Data-Driven Tests 


Existem situações em que é necessário testar várias combinações 
de entradas para o mesmo cenário. Por exemplo: para testar se um 
método que deve validar os valores de um contracheque para 
indicar se ele é valido ou se há fraude. Em um contracheque há 
vários valores de recebimentos e descontos. Imagine testar as 
várias combinações possíveis que podem resultar em válido ou 
inválido. O Spock possui um recurso chamado Data-Driven Tests, 
que facilita muito a criação de testes para situações como esta. 
Esse recurso é abordado no capítulo 5. Data-Driven Testing - 
Facilitando os testes de múltiplos cenários. 


Adoção crescente 


Segundo dados do portal javalibs.com, até o final de 2017 havia 
cerca de 14.460 artefatos Maven e repositórios GitHub que tinham o 
Spock framework como dependência. Para se ter uma ideia da 
relevância desse valor, o Spring Boot tinha o número 10.790 para o 
mesmo ano (falaremos um pouco mais sobre esse framework no 
capítulo 11. Testes de integração em projetos Spring). Em 2014, 
eram pouco mais de 2.900. Esse crescimento exponencial na 
adoção dessa ferramenta pode ser visto nas figuras a seguir e 
consultado de forma atualizada em https://javalibs.com/. 
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Figura 1.1: Repositórios com Spock framework em suas dependências. Fonte: 
https://javalibs.com/artifact/org.spockframework/spock-core 
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Figura 1.2: Repositórios com Spring Boot em suas dependências. Fonte: 
https://javalibs.com/artifact/org.springframework.boot/spring-boot 


Um fato interessante ocorreu no final de 2013: foi lançada a versão 
2.3 do framework Grails, um dos mais populares da plataforma 


Java. A partir dessa versão, o Spock passou a ser sua ferramenta 
padrão para a criação de testes unitários e de integração. Veja mais 
em https://grails.github.io/grails2- 
doc/2.3.0/guide/introduction.htmlfiwhatsNew23. 


Constante evolução 


O Spock framework foi criado por Peter Niederwieser e Luke Daley 
em 2008, mas seu primeiro release foi em 2009. Teve alguns hiatos 
quando ficou sem novas versões em 2011, 2013 e 2014, mas, 
desde 2015, tem tido sofrido atualizações com uma boa frequência. 
O histórico completo de releases no Maven Central pode ser 
encontrado em: 


https://mvnrepository.com/artifact/org.spockframework/spock-core. 


Desde seu lançamento até maio de 2017, já foram 32 releases 
sendo 6 apenas em 2017. É possível constatar o quão é ativo o 
projeto vendo a atividade em torno do seu código-fonte no GitHub 
(https://github.com/spockframework/spock). 


Conclusão 


Neste capítulo, vimos os principais motivos que justificam a adoção 
do framework Spock assim como um breve histórico e apanhado 
sobre seu estado atual de adoção. No próximo capítulo, veremos 
como configurar um projeto para o uso do Spock. 


CAPÍTULO 2 
Preparando o ambiente para trabalhar com 
Spock 


A configuração de um ambiente Spock consiste basicamente em 
preparar o ambiente para a linguagem Groovy e incluir algumas 
dependências Maven, Gradle ou SBT no projeto onde o Spock será 
usado. A seguir será demonstrado como realizar essas duas ações. 


2.1 Configurando o Groovy nas principais IDEs 
Java 


Como o Spock é uma ferramenta para a escrita de testes em 
projetos para a plataforma Java, é natural que sejam usadas as 
principais IDEs dessa plataforma. Não é necessária a instalação de 
plugin específico para Spock, mas devemos habilitar a capacidade 
de editar e compilar arquivos Groovy na IDE. Eclipse, IntelliJ Idea 
e NetBeans possuem suporte para Groovy conforme detalhado a 
seguir. 


Eclipse 


Existe um conjunto de plugins para Groovy, o Groovy-Eclipse que, 
historicamente, possui versão compatível com a última ou penúltima 
versão do Eclipse. Para instalá-lo, o processo é o mesmo de 
instalação de qualquer plugin: basta adicionar o Update Site 
conforme a versão do Eclipse desejada. As versões disponíveis 
constam na sua wiki (https://github.com/groovy/groovy-eclipse/wiki). 
Dentre os plugins que serão listados para instalação, os necessários 
para o uso do Spock são: 


e Groovy-Eclipse feature 


e Groovy Compiler 2.4 (ou versão mais atual, conforme versão do 
Spock que adotar) 
e Groovy-Eclipse M2E integration 


IntelliJ IDEA 


O IntelliJ IDEA, mesmo na versão Community Edition, já conta 
com plugin para Groovy embarcado. Assim, não é necessária a 
instalação de qualquer complemento nesta IDE. Este plugin, como o 
do Eclipse está em constante atualização. 


Caso o leitor opte por usar esta IDE, talvez não consiga executar 
individualmente os testes escritos em Spock como testes JUnit 
mesmo que seus arquivos compilem. A IDE pode informar que não 
se trata de uma classe JUnit. Caso isso ocorra, basta marcar o 
diretório src/test/groovy como "Test Sources Root" (ou " Test Sources" 
em versões até 2017). 


NetBeans 


O NetBeans, em sua versão All, já vem com funcionalidade nativa 
para trabalhar com arquivos Groovy. Caso o leitor trabalhe com 
outra versão dessa IDE, basta adicionar o plugin Groovy and 
Grails, criado e mantido pela própria equipe do NetBeans. Diferente 
dos plugins do Eclipse e IntelliJ, este está um tanto desatualizado. 
Até o fechamento desta obra, não constavam atualizações nele 
desde setembro de 2016. 


2.2 Uso de Groovy em editores de código 
simples (Sublime Text, Brackets, Atom etc.) 


Caso o leitor prefira usar uma IDE "leve", ou seja, editores de código 
como Sublime Text, Brackets, Atom, VIM, Notepad++ e similares, 


é necessário apenas instalar o Groovy e sua Development Kit (GDK) 
no sistema operacional como orientado a seguir. 


Groovy no Linux e Mac OS - SDKMAN 


Para Linux e Mac OS, a instalação recomendada é pelo uso do 
SDKMAN (http://sdkman.io/), que é uma Command Line Interface 
(CLI) que permite a instalação de Groovy e outras ferramentas de 
desenvolvimento. Para instalar o SDKMAN, basta usar o seguinte 
comando: 


curl -s get.sdkman.io | bash 


Siga as instruções conforme seu sistema operacional e 
configurações locais. Depois, execute o seguinte comando: 


source "$HOME/.sdkman/bin/sdkman-init.sh" 


Após instalar o SDKMAN, para instalar a versão mais recente do 
Groovy e seu Development Kit, use o seguinte comando: 


sdk install groovy 
Groovy no Windows - Instalador 


Para Windows, a instalação recomendada é pelo uso de um 
instalador padrão ("assistente" de instalação visual). Ele pode ser 
encontrado em: https://bintray.com/groovy/Distributions/Windows- 
Installer/viewffiles/. 


Comandos Groovy após sua instalação 


Após a instalação, seja via SDKMAN (Linux e Mac) ou instalador 
(Windows), o PATH é configurado e os seguintes comandos ficam 
disponíveis no sistema operacional: 


e groovy: Comando para execução de arquivos .groovy 
e groovyc: Compilador 
e groovysh: Terminal Groovy 


e groovyConsole: IDE minimalista da linguagem Groovy 


Para que um projeto que usa a linguagem Java ou qualquer outra 
linguagem da plataforma Java possa usar o Spock para a criação de 
testes automatizados também é necessário configurar algumas 
dependências Maven, Gradle ou SBT, conforme a tecnologia de 
gerenciamento de dependências de seu projeto. Todas as versões 
do Spock estão nos principais repositórios públicos de bibliotecas. A 
seguir, as configurações para cada um desses gerenciadores de 
dependência. 


2.3 Configurando as dependências Spock do 
projeto com Maven 


Caso seu projeto use o Maven como gerenciador de dependências, 
é necessário apenas configurar um plugin e uma dependência. No 
código do exemplo a seguir é demonstrado como seria a 
configuração do plugin obrigatório para que os testes escritos em 
Groovy sejam compilados e executados na etapa de test do build do 
Maven. A versão instalada foi a 1.6 , que era a mais atual durante a 
conclusão desta obra. 


<plugin> 
<groupld>org.codehaus.gmavenplus</groupId> 
<artifactId>gmavenplus-plugin</artifactId> 
<version>1.6</version> 
<executions> 
<execution> 
<goals> 
<goal>compile</goal> 
<goal>addTestSources</goal> 
<goal>compileTests</goal> 
</goals> 
</execution> 
</executions> 
</plugin> 


No código do exemplo a seguir é mostrado como incluir a 
dependência mínima da versão mais recente do Spock framework. 


<dependency> 
<groupId>org.spockframework< /groupId> 
<artifactId>spock-core</artifactId> 
<version>1.1-groovy-2.4</version> <!-- ou a versão que preferir --> 
<scope>test</scope> 

</dependency> 


A dependência recém-apresentada já é o suficiente para usar o 
Spock. Porém, questões como correção de bugs ou compatibilidade 
com outras bibliotecas podem forçar o uso de uma versão do 
Groovy diferente da que está configurada para a versão do Spock 
que configurou. Nesses casos, deve-se incluir uma dependência 
específica, como no próximo código, que faria o Maven usar a 
versão 2.4.12 do Groovy. 


<dependency> 
<groupld>org.codehaus.groovy</groupId> 
<artifactId>groovy-all</artifactId> 
<version>2.4.12</version> <!-- ou a versão que precisar --> 
<scope>test</scope> 

</dependency> 


2.4 Configurando as dependências Spock do 
projeto com Gradle 


Caso seu projeto use o Gradle (caso dos projetos Android) como 
gerenciador de dependências, é necessário apenas configurar um 
script plugin e uma dependência. 


O script plugin que deve ser configurado no Gradle é o groovy, 
cuja configuração é demonstrada no código a seguir. 


apply plugin: 'groovy' 


No código do exemplo a seguir é mostrado como incluir a 
dependência mínima da versão mais recente do Spock framework. 


testCompile “org.spockframework:spock-core:1.1-groovy-2.4" 


Assim como com Maven, questões como correção de bugs ou 
compatibilidade com outras bibliotecas podem forçar o uso de uma 
versão do Groovy diferente da que está configurada para a versão 
do Spock instalada. Nesses casos, deve-se incluir uma dependência 
específica, como no próximo código, que faria o Gradle usar a 
versão 2.4.12 do Groovy. 


testCompile “org.codehaus.groovy:groovy-all:2.4.12" 


No caso do Gradle, não é necessário instalar o plugin gmavenplus 
pois, o Gradle já possui suporte nativo à linguagem Groovy. 


2.5 Configurando as dependências Spock do 
projeto com SBT 


Quem trabalha com projetos em Scala normalmente usa o SBT 
(Simple Build Tool) como gerenciador de dependências. Nesse 
caso, é necessário apenas configurar um plugin e uma 
dependência. No código do exemplo a seguir é demonstrado como 
seria a configuração do plugin obrigatório para que os testes 
escritos em Groovy sejam compilados e executados na etapa de 
test dO build do SBT. A versão instalada foi a 1.6. 


addSbtPlugin("org.codehaus.gmavenplus" % "gmavenplus-plugin" % "1.6") 


No código do exemplo a seguir é mostrado como incluir a 
dependência mínima da versão mais recente do Spock framework. 


libraryDependencies += "org.spockframework" % "spock-core" % "1.1-groovy- 
2.4" % "test" 


Assim como com Maven e Gradle, questões como correção de bugs 
ou compatibilidade com outras bibliotecas podem forçar o uso de 
uma versão do Groovy diferente da que está configurada para a 
versão do Spock instalada. Nesses casos, deve-se incluir uma 
dependência específica, como no próximo código, que faria o SBT 
usar a versão 2.4.12 do Groovy. 


libraryDependencies += “org.codehaus.groovy" % "“groovy-all" % "2.4.12" % 
"test" 


Note que, em todos os gerenciadores de dependência, incluímos o 
Spock e o Groovy no escopo test. Isso foi para deixar claro que usar 
Spock para escrever os testes não implica em levar o Groovy para o 
código que vai para o ambiente de produção do seu projeto. 


Para saber se as configurações estão corretas, basta solicitar um 
clean € depois install de sua ferramenta de build . Se nenhum erro 
ocorrer, seu ambiente de desenvolvimento está pronto para a 
criação de testes automatizados com Spock. 


2.6 Experimentando o Spock on-line 


Caso você queira experimentar ou demonstrar o Spock sem 
configurar absolutamente nada, é possível usar uma ferramenta on- 
line chamada Spock Web Console, acessível via navegador em 
http://meetspock.appspot.com/. Não é preciso nenhum plugin 
instalado no navegador para usá-la. Com ela, você pode criar e 
executar testes em Spock, conforme o exemplo de execução na 
figura a seguir. 


Spock Web Console 


1 import spock.lang.* 

2 

3 class MathTest extends Specification ( 
q def '2 ao quadrado deve ser 2'() { 

5 expect: 

6 Math.pow(2, 2) == 3 

1 } 

5) 

9 


E 





POUEI A Run Script : New Script : Publish Script : View Recent Scripts 





Result Stack Trace ; 


MathTest 
- 2 ao quadrado deve ser 2 FAILED 





Condition not satisfied: 
Math.pow(2, 2) = 3 

| | 

4.0 false 


at MathTest.2 ao quadrado deve ser 2(Scriptl.groovy:6) 








Figura 2.1: Exemplo de execução de teste no Spock Web Console. 
Conclusão 


Neste capítulo foram explicadas e exemplificadas quais 
configurações são necessárias para começar os trabalhos com 
Spock framework. Também foi apresentado o Spock Web Console, 
que permite testar imediatamente o Spock, via browser. No próximo 
capítulo começaremos a criar nossos primeiros testes. 


CAPÍTULO 3 
Primeiros testes automatizados com Spock 


No capítulo anterior, vimos como preparar o ambiente para trabalhar 
com Spock. Agora, com o ambiente configurado e testado, podemos 
criar nossos primeiros testes com Spock. Neste capítulo veremos 
onde criá-los e as formas de execução dos testes. As saídas 
geradas pelos resultados dos testes também serão explicadas. 


3.1 Primeiro teste: A classe Math calcula 
potência corretamente? 


Se tiver criado um projeto Maven, Gradle ou SBT basta criar suas 
classes Groovy de teste no diretório src/test/groovy . E nele que 
criaremos nosso primeiro teste com Spock. 


Nosso primeiro teste vai testar a class math do Java, para verificar se 
seu método pow() calcula corretamente uma potência. É claro que 
esse método da API do Java funciona e não precisaríamos testá-lo. 
Esse primeiro exemplo é apenas para que nosso primeiro contato 
com o Spock seja rápido e de fácil compreensão. Vejamos o código 
a seguir, que pode ser criado em um arquivo chamado 
MathTest.groovy , já que faremos testes para a classe math . 


package unit.br.com.livrospockframework.capituloo3 
import spock.lang.Specification 


class MathTest extends Specification { 
def '2 ao quadrado deve ser 4'() { 
expect: 
Math.pow(2,2) == 


Nesse código, note que usamos a declaração de package (pacote) do 
Java. O pacote dos testes Spock pode ser qualquer um e, assim 
como em Java, apenas indica o caminho relativo de diretórios onde 
o arquivo está no diretório de códigos-fontes do projeto. Apenas 
para deixar claro quando estamos descrevendo códigos de testes 
ou não, os de teste estarão sempre em subpacotes de unit... 


O próximo detalhe a destacar é que a classe de teste é uma 
subclasse de spock.lang.Specification . Todo teste com Spock deve 
ser uma subclasse de Specification para que funcione com todas 
as funcionalidades do framework. 


Note ainda que a classe não é public . Na verdade, ela é pública. É 
que o termo public é opcional em Groovy e, se omitido, significa que 
a classe será pública em tempo de execução. 


Algo que pode parecer estranho para quem nunca teve contato com 
Groovy é que o nome do método é uma frase entre aspas. Isso é 
permitido em Groovy e facilita muito a criação de testes, afinal, cada 
método de teste em uma classe de testes automatizados deveria 
executar um cenário de teste. Qual nome de método deixa mais 
claro o cenário a ser testado: def doisAoQuadradoDeveSerQuatro() OU def 
'2 ao quadrado deve ser 4'() ? Essa sintaxe é muito usada em testes 
com Spock, sendo predominante na documentação oficial. 


O bloco expect: indica onde está a verificação (teste lógico) que 
determina o resultado do teste. Sem ele, o teste não teria sido 
executado. Outra característica muito importante é que as 
verificações em Spock normalmente contêm literalmente testes 
lógicos e não métodos, como se faz em JUnit. No exemplo há 
somente 1 verificação, porém, pode haver quantas forem 
necessárias e o teste só passará se todas passarem. O exemplo a 
seguir demonstra como seria um teste que faz mais de uma 
verificação nesse bloco. 


class MathTest extends Specification { 
def 'sgrt deve calcular a raiz quadrada'() { 
expect: 


Math.sgrt(4) == 2 
Math.sgrt(25) == 5 
Math.sgrt(144) == 12 


} 


Nesse exemplo, queríamos saber se o método sqrt da classe math 
realmente calcula a raiz quadrada corretamente e, para isso, 
fizemos 3 verificações no bloco expect . 


Caso você tenha pouco conhecimento sobre Groovy, o Apêndice 


A - Guia de Groovy para desenvolvedores Java possui um 
conteúdo que dá o caminho das pedras dessa linguagem. 





3.2 Executando um teste 


Para executar todas as classes de teste de um projeto, basta 
executar o comando de seu gerenciador de dependências que 
invoca os testes do projeto. No Maven, por exemplo, todos os goals 
menos O compile promovem a execução dos testes do projeto. 


A execução de apenas uma classe de testes pode ser feita 
usando o comando específico de seu gerenciador de dependência 
recomendado para isso. No Maven, o comando seria como o do 
exemplo a seguir. 


mvn -Dtest=MathTest test 

No Gradle, o comando seria como o do próximo código. 
gradle -Dtest.single=MathTest test 

Já no SBT, o comando seria como o do código a seguir. 


sbt test:test-only *MathTest 


Caso use uma IDE completa (Eclipse, IntelliJ ou NetBeans), ela 
permitirá a execução da classe mathtest como se fosse uma classe 
JUnit. Ou seja, basta pedir a execução da classe que o teste 
unitário nela será executado. Essas IDEs permitem ainda a 
execução de apenas um dos métodos na classe de teste. Caso use 
uma IDE simples (Sublime Text, Atom, Brackets etc.), sua única 
alternativa será executar o comando de execução individual de 
testes de seu gerenciador de dependências, conforme os três 
Últimos códigos de exemplo. 


Caso o teste compile e seja executado, ele gerará uma saída no log 
de execução como a do exemplo a seguir. 


Running unit.br.com.livrospockframework.capituloo3.MathTest 
Tests run: 1, Failures: ©, Errors: ©, Skipped: ©, Time elapsed: 0.156 sec 


Results : 


Tests run: 1, Failures: ðO, Errors: ©, Skipped: O 


3.3 O que acontece quando um teste falha 


Um teste pode falhar por exceção não esperada em tempo de 
execução ou porque ao menos uma das verificações nele não 
passou. Vejamos o que ocorre em cada uma dessas situações. 


Teste que falha por exceção 


Tomemos como exemplo o código a seguir, que possui uma sutil 
diferença em relação ao anterior, na qual trocamos a base por uma 
divisão entre 1 e 0. 


package unit.br.com.livrospockframework.capituloo3 
import spock.lang.Specification 


class MathTest extends Specification { 
def '2 ao quadrado deve ser 4'() { 
expect: 
Math.pow((1/0), 2) == 4 


} 


Esse código vai compilar, mas provocará uma exceção em tempo de 
execução, pois 1/0 em Groovy, assim como em Java, resulta em 
uma java.lang.ArithmeticException: Division by zero. Ao ser executado, 
o teste geraria uma saída no log como a do exemplo a seguir: 


2 ao quadrado deve ser 4(MathTest) Time elapsed: 0.054 sec <<< FAILURE! 
Condition failed with Exception: 


Math.pow( (1/0), 2) == 5 


java.lang.ArithmeticException: Division by zero 


at MathTest.2 ao quadrado deve ser 4(MathTest.groovy:6) 
Caused by: java.lang.ArithmeticException: Division by zero 
at java.math.BigDecimal.divide(BigDecimal.java:1742) 


Como é possível notar, o log de erro do Spock indica o local exato 
que provocou a exceção. Com outras ferramentas de testes, 
saberíamos a linha, mas não o ponto exato. Note ainda como o log 
fica mais fácil de ser lido, pois o nome do método é, literalmente, o 
nome do cenário. 


O formato e os detalhes da saída gerada pelo Spock ajudam muito 
naquelas situações em que ocorre o clássico NullPointerException . 
Vamos simular esse tipo de exceção a partir do código de teste a 
seguir, no qual declaramos um Double base = null propositalmente 
para que a invocação de seu .intvalue() provoque uma exceção. 


package unit.br.com.livrospockframework.capituloo3 
import spock.lang.Specification 


class MathTest extends Specification { 
def '2 ao quadrado deve ser 4'() { 
Double base = null 
expect: 
Math.pow(base.intValue(), 2) == 4 


} 


Ao ser executado, esse teste resultaria em um log como este a 
seguir. 


2 ao quadrado deve ser 4(MathTest) Time elapsed: 0.058 sec <<< FAILURE! 
Condition failed with Exception: 


Math.pow(base.intValue(), 2) == 


java.lang.NullPointerException: Cannot invoke method intValue() 
on null object 


at MathTest.2 ao quadrado deve ser 4(MathTest.groovy:7) 
Caused by: java.lang.NullPointerException: Cannot invoke method intValue() 
on null object 

at java.math.BigDecimal.divide(BigDecimal.java:1742) 


Note que o exato objeto que provocou O NullPointerException é 
indicado, evitando ajustes e/ou novas execuções para descobrir 
quem é o culpado pela exceção. 


Como foi demonstrado nos exemplos, o ponto específico onde 
ocorreu a exceção ficaria indicado, o que facilita muito o tratamento 
do problema. Com outras ferramentas, teríamos que, ou executar 
várias vezes mexendo um pouco no código (tentativa e erro) ou 
teríamos que executar o teste em modo debug caso a IDE usada 
possua esse recurso. 


Teste que não passa em uma verificação 


Comparação entre números 


Tomemos como exemplo o código a seguir, que é muito parecido 
com o anterior, porém, contém um erro proposital no resultado 
esperado (5 em vez de 4 como resultado esperado para 2 ao 
quadrado). 


package unit.br.com.livrospockframework.capituloo3 
import spock.lang.Specification 


class MathTest extends Specification { 
def '2 ao quadrado deve ser 4'() { 
expect: 
Math.pow(2, 2) == 


} 


Esse código vai compilar e executar sem exceção alguma. Porém, a 
verificação configurada no bloco expect vai falhar, pois 2 ao 
quadrado não é igual a 5. Ao ser executado, o teste geraria uma 
saída no log como a do exemplo a seguir: 


Running unit.br.com.livrospockframework.capituloð3.MathTest 

Tests run: 1, Failures: 1, Errors: ©, Skipped: ©, Time elapsed: 0.185 sec 
<<< FAILURE! 

2 ao quadrado deve ser 4(MathTest) Time elapsed: 0.059 sec <<< FAILURE! 
Condition not satisfied: 


Math.pow(2, 2) == 


4.0 false 


at MathTest.2 ao quadrado deve ser 4(MathTest.groovy:8) 


Como é possível notar novamente, o log de erro do Spock indica o 
local exato da falha de verificação e os valores envolvidos no 
teste. Ficaram claros não só a linha da falha, mas também os 
valores comparados. Note que o resultado de pow(2,2) ficou explícito 
no log. Isso nos poupa de criar uma mensagem de erro 
recuperando, manualmente, o resultado do método. 


Comparação entre alfanuméricos 


Quando criamos testes que comparam valores alfanuméricos ( 
String ), além de apontar que existe a diferença, o Spock gera um 
pequeno relatório estatístico das diferenças. Para ver como isso 
funciona, vamos criar outra classe de teste, a stringtest . Nela, 
vamos testar os métodos touppercase() € substring() da biblioteca 
padrão do Java. 


class StringTest extends Specification { 
def "toUpperCase() deveria por tudo em caixa alta"() { 


expect: 
"bom dia”.toUpperCase() == "Bom Dia” 
} 
def "substring() deveria extrair a parte desejada do texto"() { 
expect: 
"sejam bem vindos!".substring(1,5) == "sejam" 
} 


} 


No último código, montamos 2 testes que vão falhar. O objetivo é 
que você veja como é o log que o Spock gera em caso de falha na 
comparação entre diferentes objetos string . A execução desse teste 
geraria logs como dos textos a seguir. 


toUpperCase() deveria por tudo em caixa 
alta(unit.br.com.livrospockframework.capituloð03.StringTest) Time elapsed: 
0.208 sec <<< FAILURE! 

org.spockframework.runtime.SpockComparisonFailure: Condition not 
satisfied: 


"bom dia".toUpperCase() == "Bom Dia" 
| | 
BOM DIA false 
4 differences (42% similarity) 
B(OM) D(IA) 
B(om) D(ia) 


substring() deveria extrair a parte desejada do 
texto(unit.br.com.livrospockframework.capitulo03.StringTest) Time 
elapsed: 0.006 sec <<< FAILURE! 


org.spockframework.runtime.SpockComparisonFailure: Condition not 


satisfied: 
"sejam bem vindos!".substring(0,4) == "sejam" 
| | 
seja false 
1 difference (80% similarity) 
seja(-) 
seja(m) 


Note nos 2 logs anteriores que, além de serem indicados o local 
exato da diferença e quais os valores esperado e recuperado, são 
descritos uma porcentagem de semelhança e os detalhes de cada 
posição no texto onde foram encontradas diferenças. 


Comparação entre coleções 


Ao comparar o conteúdo ou o tamanho de coleções, o Spock 
imprime no log não só a linha e o ponto da diferença como os 
conteúdos das coleções envolvidas. Vamos criar mais um teste, o 
CollectionsTest (veja no próximo código-fonte), no qual teremos 3 
testes entre coleções. Caso fique com dúvidas sobre a lista e/ou o 
mapa criados com Groovy, não se esqueça de que pode recorrer ao 
Apêndice A - Guia de Groovy para desenvolvedores Java 


class CollectionsTest extends Specification ( 


def "listas devem ser iguais'() { 
expect: 
def listal = ['café','leite','açúcar'] 
def lista? = ['café','leite','adoçante'] 
listal == lista? 


def 'mapas devem ser iguais'() 1 
expect: 
def mapa1 = [PA:'Pará', SP:'São Paulo", MG:'Minas Gerais'] 
def mapa? = [DF:'Distrito Federal', GO:'Goiás', PR:'Paraná'] 
mapal == mapa2 


def 'listas devem ser ter o mesmo tamanho" () { 
expect: 
def listal = ['uva','morango','amora'] 
def lista? = ['abacate','maçã verde'] 
listal.size() == lista2.size() 


} 


No primeiro teste, comparamos o conteúdo de 2 listas (List ). No 
segundo, comparamos o conteúdo de 2 mapas ( map ). Já no terceiro 
teste, comparamos o tamanho de 2 listas ( List ). Todos eles vão 
falhar. O log produzido será com o exemplo a seguir. 


listas devem ser iguais (...) Condition not satisfied: 


listal == lista? 

| | 

| | [café, leite, adoçante] 
| false 

[café, leite, açúcar] 


mapas devem ser iguais (...) Condition not satisfied: 


mapal == mapa2 

| | 

| | [DF:Distrito Federal, GO:Goiás, PR:Paraná] 
| false 

[PA:Pará, SP:São Paulo, MG:Minas Gerais] 


listas devem ser ter o mesmo tamanho (...) Condition not satisfied: 


listal.size() == lista2.size() 

| | | | 

| 3 | 2 

| | [abacate, maçã verde] 
| false 

[uva, morango, amora] 


Note no log dos 3 testes com coleções que, além de indicar o ponto 
exato da falha do teste, o Spock imprimiu os conteúdos das 
coleções comparadas. 


Conforme demonstram os exemplos que acabamos de ver, 
independente do que estamos comparando, o Spock nos fornece 
muitos detalhes. Isso reduz muito a necessidade de tentativa e erro 
e da execução dos testes em modo debug da IDE para identificar e 
corrigir o problema. 


Conclusão 


Neste capítulo, criamos nossos primeiros testes com Spock. Vimos 
como criar um teste simples e as formas de executá-lo. Também 
vimos como o Spock registra os testes em caso de exceção ou falha 
de verificação. No próximo capítulo veremos com mais detalhes a 
anatomia dos testes criados com esse framework. 


CAPÍTULO 4 
Anatomia de um teste Spock 


No capítulo anterior, criamos nossos primeiros testes com o Spock e 
vimos como são as saídas produzidas em caso de sucesso e falha 
na execução. Neste capítulo veremos os conceitos e convenções do 
framework Spock para que possamos compreender melhor a 
anatomia dos testes criados com essa ferramenta. Isso será muito 
importante para a criação de testes melhores e com código menor e 
mais organizado. 


4.1 Testes são chamados de Specifications 


Uma classe de teste no Spock é chamada em sua documentação 
oficial de Specification. Por isso, ela apresenta as classes de teste 
com o sufixo spec no nome. A classe mathtest criada no capítulo 
anterior, por exemplo, poderia ter o nome alterado para mathspec , se 
fôssemos seguir a convenção da documentação do Spock. 


Criar as Specifications com o sufixo Test possui algum efeito 
colateral? 


Não. Inclusive todos os testes neste livro terão o sufixo Test no 
nome. A razão disso é que, além de continuarem funcionando 
perfeitamente, seguem a convenção do Maven e afins, que 
executam os testes em classes que terminam com esse termo e 
estão no diretório src/test . 


E se eu preferir usar o sufixo Spec nos nomes de meus testes? 


Você perderá a execução automática dos testes pelo Maven, pois 
ele não vai considerar essas classes como testes a serem 


executados, mesmo se estiverem no diretório src/test . Para que 
executem os testes em classes com o sufixo spec , é necessário 
adicionar uma configuração apropriada para o gerenciador de 
dependências que estiver usando. A seguir, exemplos de como 
fazer configurar isso no Maven. No Gradle e no SBT essa 
configuração não é necessária. 


Configurando o Maven para compilar e executar testes com o sufixo 
Spec : 


<plugin> 
<artifactId>maven-surefire-plugin</artifactId> 
<version>2.18.1</version> <!-- ou versão mais recente --> 


<configuration> 
<includes> 
<include>**/*Spec.groovy</include> 
<include>**/*Spec. java</include> 
<include>**/*Test.groovy</include> 
<include>**/*Test.java</include> 
</includes> 
</configuration> 
</plugin> 


Note que tivemos que indicar que arquivos .groovy € .java COM OS 
sufixos spec € Test devem ser considerados classes de teste. É 
preciso incluir todos esses 4 padrões, caso contrário, se o projeto já 
possuir testes legados em JUnit, eles deixariam de ser executados. 


Toda classe de teste deve ser subclasse de 
spock. lang.Specification 


Nos exemplos abordados no capítulo anterior vimos isso e, como já 
foi dito lá, essa herança é realmente necessária. As classes de 
testes podem estender diretamente ou indiretamente (ou seja, 
estender outra que estenda) a spock.lang.Specification . Ao estender 
essa classe, todos os recursos do framework Spock ficam 
disponíveis para a classe de teste. 


4.2 Uma classe de teste pode conter vários 
métodos de teste 


Em geral costuma-se criar uma classe de testes para cada classe 
no projeto. E, para cada método da classe testada, criam-se vários 
métodos de teste, de acordo com a quantidade de cenários 
necessários. O Spock permite a criação de quantos métodos de 
teste forem necessários na mesma classe de teste. Um exemplo 
desse tipo de situação está na figura a seguir. 


Classe a ser testada Classe de testes 


public class LadyGaga ( class LadyGagaTest extends Specification { 


public void metodol() 4 "+ def 'metodol deveria funcionar'() { 


} } 
public void metodo2(int pl, String p2) def 'metodo2 deveria funcionar com pl e p2'() { 
} } 


} 


def 'metodo2 deveria funcionar apenas com p1'() { 


} 


def 'metodo2 deveria funcionar apenas com p2'() { 


} 


Figura 4.1: Classe a ser testada x classe de testes. 


A figura ilustra a seguinte situação: tínhamos que testar a minhaclasse 
, Que possui 2 métodos ( metodo1 € metodoz ). Foi criada a classe de 
testes minhaclasseTest com 4 métodos (cenários) de teste, sendo 
apenas 1 para testar O metodo1 e 3 para testar O metodo . 


4.3 Fixture Methods (métodos de montagem) 


Imagine os testes de uma classe que acessa um banco de dados: 
antes da execução dos testes, seria bem útil configurar um banco de 
dados temporário, para evitar que a execução de testes crie "lixo" 
em uma base de dados real. Ao final da execução dos testes, esse 
banco de dados deveria ser completamente eliminado. Situações 
como a desse exemplo são comuns em testes unitários mais 
complexos e em testes de integração. 


Nessas situações, onde é necessário preparar um ambiente para a 
execução dos testes e/ou executar ações após a execução, O uso 
de fixture methods (ou métodos de montagem, em tradução livre) 
é bastante recomendado. Eles são uma forma de implementar o 
ciclo de vida de testes proposto no padrão Four-phase test. 


PADRÃO FOUR-PHASE TEST 


"Teste de quatro fases”, em tradução livre. Foi proposto por 
Gerard Meszaros em seu livro clássico XUnit Test Patterns - 
Refactoring Test Code, de 2007. Esse padrão propõe que a 
execução dos cenários de testes possua 4 (quatro) fases: 


Setup, em que se configura o necessário para a execução e 
validação dos testes. 

Exercise, em que é executada a ação que é alvo do teste. 
Verify, em que é verificado se a ação fez o que era 
esperado. 

Teardown, em que todos os recursos alocados pelo teste 
(objetos em memória, arquivos em disco, conexões com 
outros sistemas etc.) devem ser liberados. 


O conceito de Four-Phase pode ser encontrado em 


http://xunitpatterns.com/Four%20Phase%20Test.html e ilustrado 
na figura a seguir. 


testMethod 1) T 


Setup 
Exercise 
Veil) 
[Teardowir 


Figura 4.2: Padrão Four-phase test. Fonte: 
http://xunitpatterns.com/Four%20PhaseY%20Test.html 





Os fixture methods do Spock framework são: setup, setupSpec, 
cleanup e cleanupSpec. 


setup() 


Caso exista na classe de testes, é executado antes de cada 
método de teste. Para deixar claro: caso existam 4 métodos de 
teste, esse método será executado 4 vezes, antes de cada um 
deles. 


cleanup() 


Caso exista na classe de testes, é executado depois de cada 
método de teste. Para deixar claro: caso existam 4 métodos de 
teste, esse método será executado 4 vezes, depois de cada um 
deles. 


setupSpec() 


Caso exista na classe de testes, é executado apenas uma vez 
antes de todos os métodos de teste. Para deixar claro: caso 
existam 4 métodos de teste, esse método será executado apenas 1 
vez, antes da execução do primeiro teste. Caso exista também um 
setup() na mesma classe, sua primeira execução será depois do 
setupSpec() . 


cleanupSpec() 


Caso exista na classe de testes, é executado apenas uma vez 
depois de todos os métodos de teste. Para deixar claro: caso 
existam 4 métodos de teste, esse método será executado apenas 1 
vez, depois da execução do último teste. Caso exista também um 
cleanup() na mesma classe, sua última execução será antes do 
setupSpec() . 


A relação entre as fases do padrão Four-phase test e os fixture 
methods do Spock está representada na figura a seguir. 


Método 


e 


setup) 


Exercise | 'método de teste'() 


ame 


Teardown |cleanup() 


cleanupSpec() 





Figura 4.3: Relação entres as fases do Four-phase test e os fixture methods do Spock. 


Para deixar bem clara a ordem e quantidade de execuções dos 
fixture methods, observe a classe de testes de exemplo a seguir. 


class MinhaClasseTest extends Specification ( 
def setupSpec() {} 


def setup() {} 

def 'metodo1 deveria funcionar'() {} 
def 'metodo2 deveria funcionar'() {} 
def cleanup() () 

def cleanupSpec() {} 


Ao ser executada, os métodos seguiriam a ordem de execução 
indicada no diagrama de atividade a seguir. 


setupSpec() 
setup() ‘método de teste'() 


[Ainda há teste para executar] O 


[Não há mais testes] 


cleanupSpec() 


Figura 4.4: Ordem de execução dos fixture methods em uma classe de testes Spock. 









Importante: mesmo que os testes falhem por exceções ou por 
validações, todos os fixture methods são executados. 


4.4 Blocks (Blocos) 


Imagine a situação em que uma classe de acesso a banco de dados 
possui vários métodos e cada um faz operações tão diferentes entre 
si que, para testá-los, seria necessário um banco de dados 
temporário diferente para cada. Ou seja, os diversos cenários de 
teste precisariam de setups e/ou de cleanups diferentes. 
Considerando apenas o recurso dos fixture methods, a saída seria 
criar várias classes de testes, uma para cada cenário de teste. 
Porém, para situações como esta, o Spock possui um interessante 
recurso chamado Blocks (Blocos, em tradução livre), com o qual é 
possível dividir as etapas de execução de um teste dentro de 
método de teste. 


Quanto à sua sintaxe, seu nome é sempre acompanhado por dois 
pontos ( : ) e cada bloco pode conter quantas linhas de código 
forem necessárias. 


Os blocos do Spock indicam as principais etapas do ciclo de vida de 
um teste, desde a preparação até o pós-teste. São eles: setup, 
given, when, expect, then, cleanup e and. 


Conforme a combinação de blocos utilizada, o teste acaba adotando 
o padrão Four-phase test ou o Given-When-Then (GWT). 


PADRÃO GIVEN-WHEN-THEN 


A AM 


"Dado-quando-então", em tradução livre. Foi proposto por Dan 
North e Ivan Moore no artigo Introducing BDD, publicado na 
revista Better Software em março de 2006. Esse padrão propõe 


que a execução dos cenários de testes possua 3 (três) fases: 


e Given, em que são definidas as precondições do cenário. 

e When, em que é identificado o evento (a ação) do teste. 

e Then, em que é verificado se o evento ocorreu conforme o 
esperado. 





setup: 


Caso seja necessária a configuração de um ambiente para a 
execução de um cenário de teste, ela pode ser feita no bloco setup: 
Ele deve ser sempre o primeiro bloco e não pode ser usado em 
conjunto com o given: . Este bloco só pode estar presente 1 (uma) 
vez por método. 


Se usado, torna-se necessária a presença de um bloco expect: . 
given: 


Caso seja necessária a configuração de um ambiente para a 
execução de um cenário de teste, ela pode ser feita no bloco given: 
Ele deve ser sempre o primeiro bloco e não pode ser usado em 
conjunto com o setup: . Este bloco só pode estar presente 1 (uma) 
vez por método. 


Se usado, torna-se necessária a presença de um bloco expect: OU 
dos blocos when: € then: . 


when: 


É o bloco onde o evento a ser testado deve ser executado. Pode 
existir mesmo sem um bloco de preparação/configuração anterior. 
Se o bloco given: existir, deve estar necessariamente após ele. Não 
pode ser usado em conjunto com o setup: . Este bloco só pode estar 
presente 1 (uma) vez por método. 


Se usado, torna-se necessária a presença de um bloco then: . 
expect: 


É o bloco onde o evento a ser testado deve ser executado. Pode ser 
usado se o bloco de preparação/configuração usado foi O setup: OU O 
given: e deve estar, necessariamente, após um deles. Este bloco só 
pode estar presente 1 (uma) vez por método. 


É o único bloco que pode estar sozinho num método de testes, 
como foi possível feito no capítulo anterior. 


then: 


É o bloco onde o evento a ser testado deve ser executado. Só pode 
ser usado se o bloco de preparação/configuração usado foi O given: 

e deve estar, necessariamente, após um when: . Este bloco só pode 

estar presente 1 (uma) vez por método. 


cleanup: 


Este bloco será executado após o bloco de execução do evento 
usado no teste ( expect: OU then: ) mesmo que eles falhem por 
verificação ou exceção. Deve estar, necessariamente, após o 
método de execução do evento. Este bloco só pode estar presente 1 
(uma) vez por método. 


and: 


Este bloco simplesmente dá continuidade ao bloco imediatamente 
anterior, podendo ser usado após qualquer um dos outros blocos. É 
usado apenas para dividir e organizar um bloco em partes menores. 
Exemplos: se estiver após um setup: funciona como um setup: ; se 
estiver após um expect: , funciona como um expect: . Este bloco pode 
estar presente várias vezes por método. 


where: 


Este bloco deve ser usado somente no caso de Data-Driven 
Testing. Esse tipo especial de teste será abordado no capítulo 5. 


Ordem e restrição de combinações de blocos 


Os blocos não podem ficar em qualquer ordem e possuem algumas 
restrições quanto às combinações possíveis. Para ajudar a entender 
essas questões, vide a tabela a seguir. 


Não pode ser 
Bloco Ordem usado em 
conjunto com 


setup: Sempre o 1º bloco given: , when: € then: 
given: Sempre o 1º bloco setup: 
o r : . 
er 1° bloco ou após given: (e seus sabin 
and: , caso existam) 
aka Sempre após when: (e seus and: E 


, Caso existam) 


Sozinho no método ou após 
expect: setup: (e seus and: , Caso given: O when: 
existam) 


Não pode ser 
Bloco Ordem usado em 
conjunto com 


elean Sempre após expect: OU then: (e | 


seus and: , caso existam) 


and: Após qualquer outro bloco - 


Blocos para Four-phase test 


Caso o leitor adote o padrão Four-phase test, a combinação de 
blocos recomendada é setup > and > expect. A figura a seguir 
ilustra a relação entre as fases do padrão e os blocos do Spock. 


Terácum cleanup: 


Figura 4.5: Relação entres as fases do Four-phase test e os blocos do Spock. 





Blocos para Given-When-Then 


Caso o leitor adote o padrão Given-When-Then, a combinação de 
blocos recomendada é given > when > then. A figura a seguir 
ilustra a relação entre as fases do padrão e os blocos do Spock. 


Bloco 


given: 





Figura 4.6: Relação entres as fases Given-When-Then e os blocos do Spock. 


4.5 Por que a anatomia do Spock é essa 


Talvez o leitor tenha se perguntado: por que o Spock adota o termo 
Specification e não Test como o JUnit, por exemplo? Ou ainda: por 
que blocos explícitos para os padrões Given-When-Then e Four- 
phase test? É porque o Spock foi desenvolvido sob influência de 
uma técnica chamada BDD. Essa influência levou à anatomia dos 
testes do Spock abordada neste capítulo. 





BEHAVIOUR-DRIVEN DEVELOPMENT - BDD 


"Desenvolvimento Dirigido a Comportamento", em tradução livre. 
Foi proposta por Dan North e Ivan Moore no artigo Introducing 
BDD. Essa técnica fornece várias definições objetivas sobre 
como devem ser os testes em um projeto de desenvolvimento 
software. Algumas dessas definições são: 


e Nomes de métodos de teste devem ser frases, algo comum 
no Spock. 
Usar linguagem ubíqua (linguagem compreensível por 
programadores e não programadores, como analistas de 
negócio, por exemplo). O padrão Given-When-Then é um 
exemplo dessa linguagem e o Spock o implementa com os 
blocos de mesmo nome. 
Critérios de aceitação devem ser executáveis. 
"Comportamento" é uma palavra mais útil que "teste" e os 
"comportamentos" são criados em especificações 
(Specifications, por isso as classes de teste do Spock 
possuem esse sufixo, por padrão). 


O artigo completo pode ser encontrado em 
https://dannorth.net/introducing-bdd/ (versão traduzida para 
português em http://broncodev.com/2016-10-11-introduzindo-o- 
bdd/). 


Como esta obra não tem o BDD como foco e tem como principal 
público-alvo profissionais sem experiência em testes, usaremos o 
termo teste em vez de especificação. 


Spock é uma ferramenta para aplicação de BDD? 


É possível usar o Spock na adoção BDD, como ensina e exemplifica 
Konstantinos Kapelonis em seu livro Java Testing with Spock. 
Porém, na mesma obra, o autor afirma que o Spock não é uma 


ferramenta completa de BDD, indicando outras mais adequadas 
para a adoção dessa técnica. 


Conclusão 


Neste capítulo vimos os conceitos específicos do Spock e 
entendemos a anatomia de seus testes. Esses conceitos são a base 
para os demais capítulos. No próximo capítulo veremos o fascinante 
recurso de Data-Driven Testing, que facilita muito a criação de 
testes com múltiplos cenários. 


CAPÍTULO 5 
Data-Driven Testing - Facilitando os testes de 
múltiplos cenários 


No capítulo anterior, estudamos e aplicamos os conceitos e 
convenções do framework Spock. Neste capítulo veremos a 
funcionalidade chamada Data-Driven Testing (Testes Orientados a 
Dados, em tradução livre). Com ela, é possível testar vários 
cenários para uma mesma funcionalidade de uma forma muito 
simples. 


5.1 Testando um Analisador de IMC 


Imagine que precisamos desenvolver um componente que informa a 
condição de saúde com base no índice de massa corporal (o 
famoso IMC). Esse componente recebe o IMC e o sexo de uma 
pessoa e devolve uma frase com a condição de saúde 
correspondente. Para facilitar nosso exemplo, não vamos usar a 
verdadeira tabela do IMC segundo a Organização Mundial de 
Saúde, mas uma versão resumida e com valores arredondados 
como a seguir. 


Condição IMC em mulheres IMC em homens 
Abaixo do peso < 19 < 21 
Peso normal >= 19..< 26 >=21..< 27 
Acima do peso ideal >=26 >= 27 


Para implementar esse componente, vamos criar um projeto Java e 
depois 2 tipos enum em Java: sexo € FaixaImc , descritos nos códigos 
a seguir. 


package br.com.livrospockframework.capitulodO5.enums ; 


public enum Sexo { 
FEMININO, MASCULINO; 


} 


O enum sexo serve para garantir que só sejam informados os valores 
que definimos previamente. Neste caso, MASCULINO € FEMININO . 


package br.com.livrospockframework.capitulo®5.enums; 
public enum FaixaImc { 


ABAIXO("Abaixo do peso", 19, 21), 
NORMAL ("Peso Normal", 26, 27), 

ACIMA( "Acima do peso", 100, 100); 

// 100 é um IMC virtualmente impossível 


protected String descricao; 
protected double limiteMaximoFeminino; 
protected double limiteMaximoMasculino; 


// Construtor para os 3 atributos 


public static FaixaImc getFaixa(double imc, Sexo sexo) { 
FaixaImc retorno = values()[0]; 


for (int i=1; i < values().length; i++) { 


FaixaImc atual = values()[i]; 
FaixaImc anterior = values()[i-1]; 


double limiteInferior = (sexo == Sexo.FEMININO) ? 
anterior. limiteMaximoFeminino : anterior.limiteMaximoMasculino; 

double limiteSuperior = (sexo == Sexo.FEMININO) ? 
atual. limiteMaximoFeminino : atual.limiteMaximoMasculino; 


if (imc >= limiteInferior && imc < limiteSuperior) { 
retorno = atual; 


return retorno; 


// getDescricao() 


} 


O enum FaixaImc contém as condições de saúde das 3 faixas de 
nossa tabela de IMC. O método que precisaremos testar é o 
getFaixa() , que tem como argumentos o IMC e o sexo de uma 
pessoa. Ele procura e retorna a condição de saúde após análise das 
faixas de IMC e sexo. Em ambos os enums, o pacote é apenas uma 
sugestão. 


5.2 Um método, vários cenários 


Agora que temos o problema e uma proposta de implementação da 
solução, o que precisamos testar? A partir de 2 valores de 
entrada (IMC e sexo), precisamos testar 1 valor de saída (condição 
de saúde). Só precisamos testar o método getFaixa() do enum 


FaixaImc . 


O que será determinante para o sucesso de nossos testes será a 
quantidade de cenários a serem testados. Conseguiu contar 
quantos cenários devem ser testados para esse componente? São 3 
condições possíveis para mascuLIno € 3 para FEMININO . Logo, temos 
que testar 6 cenários, no mínimo. 


Classe de testes para vários cenários SEM Data-Driven Testing 


Vamos criar uma classe de testes, chamá-la de FaixaImcTest e criar 
os 6 cenários mínimos usando os recursos que aprendemos até 
aqui sobre o Spock. Veja o código-fonte a seguir. 


package unit.br.com.livrospockframework.capituloos; 
class FaixaImcTest extends Specification ( 


def 'IMC deve estar na faixa correta'() { 
expect: 
FaixaImc.getFaixa(18, Sexo.FEMININO) == FaixaImc.ABAIXO 
FaixaImc.getFaixa(21, Sexo.FEMININO) == FaixaImc.NORMAL 
FaixaImc.getFaixa(27, Sexo.FEMININO) == FaixaImc.ACIMA 
FaixaImc.getFaixa(20, Sexo.MASCULINO) == FaixaImc.ABAIXO 
FaixaImc.getFaixa(23, Sexo.MASCULINO) == FaixaImc.NORMAL 
FaixaImc.getFaixa(28, Sexo.MASCULINO) == FaixaImc.ACIMA 
} 

} 


Ao executar essa classe de teste, certamente os 6 cenários de teste 
passarão. Porém temos muita repetição de código. Vamos tentar 
melhorar isso? E se reescrevêssemos o método de teste de nossa 
classe FaixaImcTest e ele ficasse como o próximo código? 


def 'IMC deve estar na faixa correta'() { 
setup: 
def cenarios = [ 
[imc:18, sexo: Sexo.FEMININO, condicao: FaixaImc.ABAIXO], 
[imc:21, sexo: Sexo.FEMININO, condicao: FaixaImc.NORMAL], 
[imc:27, sexo: Sexo.FEMININO, condicao: FaixaImc.ACIMA], 
[imc:20, sexo: Sexo.MASCULINO, condicao: FaixaImc.ABAIXO], 
[imc:23, sexo: Sexo.MASCULINO, condicao: FaixaImc.NORMAL], 
[imc:28, sexo: Sexo.MASCULINO, condicao: FaixaImc.ACIMA] 


] 


expect: 
cenarios .eachf 
assert FaixaImc.getFaixa(it.imc, it.sexo) == it.condicao 


} 
} 


O que achou? Note que organizamos melhor o teste, dividindo-o 
explicitamente nas fases setup (em que criamos uma tabela de 
cenários com as entradas e saídas em uma lista de mapas) e expect 


(em que iteramos na tabela e cenários e testamos cada item). Caso 
tenha ficado com dúvidas na lista, nos mapas ou na iteração usados 
no último código, não se esqueça de que pode recorrer ao 
Apêndice A - Guia de Groovy para desenvolvedores Java. 


Classe de testes para vários cenários COM Data-Driven Testing 


Percebeu que foi usado o termo "tabela de cenários" para descrever 
a lista de mapas com as entradas e saídas do teste anterior? Para 
poder descrever uma tabela de cenários literalmente como uma 
tabela podemos usar o recurso de Data-Driven Testing do Spock. 


Como o nome sugere, esse recurso pode ser usado quando temos 
situações parecidas com o exemplo do IMC: onde há vários valores 
de saída a partir de várias combinações de valores de entrada. 
Outros exemplos de componentes onde esse recurso ajudaria muito 
nos testes: 


e Miniguia astral (entradas: dia e hora do nascimento / saídas: 
signo e ascendente). 

e Gerador de contracheque (entradas: vencimento e benefícios / 
saídas: descontos legais e valor líquido). 

e Simulador de resultados de um campeonato esportivo 
(entradas: resultados das partidas / saída: campeão). 


Vejamos como ficaria nosso método de teste usando esse recurso 
no código a seguir. 


def 'IMC deve estar na faixa correta'() { 
expect: 
FaixaImc.getFaixa(imc, sexo) == resultado 


where: 

resultado 
FaixaImc.ABAIXO 
FaixaImc .NORMAL 
FaixaImc.ACIMA 
FaixaImc.ABAIXO 
FaixaImc.NORMAL 


imc 
18 
21 
27 
20 
23 


sexo 
Sexo. FEMININO 
Sexo. FEMININO 
Sexo. FEMININO 
Sexo. MASCULINO 
Sexo. MASCULINO 


28 | Sexo.MASCULINO || FaixaImc.ACIMA 
} 


Veja como a configuração da tabela de cenários ficou mais alto 
nível, sendo compreensível até por não programadores. Ela foi 
escrita, literalmente, em forma de tabela, o que reduziu a repetição e 
volume de código na classe de teste. 


Quando usamos o recurso do Data-Driven Testing, o bloco expect 
vem sempre antes do bloco where . No expect indicamos o código a 
ser usado para o teste de cada cenário e no where configuramos 
quantos cenários acharmos necessários. 


Um detalhe importante são os nomes das variáveis de entrada e 
saída: OS imc € sexo usados pelo método getFaixa() € O resultado NO 
bloco expect são os mesmos das colunas imc , sexo € resultado da 
tabela no bloco where . Essa relação está ilustrada na figura a seguir. 


def "IMC deve estar na faixa correta"() { 


expect: 

FaixaImc.getFaixa(imc, sexo) == resultado 
where: 

imc | sexo || resultado 

18 | Sexo.FEMININO || FaixaImc.ABAIXO 
21 | Sexo.FEMININO || FaixaImc.NORMAL 
27 | Sexo.FEMININO || FaixaImc.ACIMA 
20 | Sexo.MASCULINO || FaixaImc.ABAIXO 


Figura 5.1: Entradas e saídas esperadas num teste com Data-Driven Testing. 


Na tabela de cenários, usamos o separador pipe (| ) como 
separador de coluna. Usamos 2 pipes (|| ) antes da coluna de 


resultado para melhor organização, mas poderíamos ter usado 
apenas 1 também. 


Certo, mas será que nosso enum FaixaImc já funciona 
perfeitamente? Afinal, nos testes anteriores, os cenários continham 
valores de IMC um tanto confortáveis, ou seja, que não ficavam nos 
limites entre as faixas. Vamos acrescentar cenários que testem os 
limites das faixas. Vide o próximo código. 


def 'IMC deve estar na faixa correta'() { 


expect: 

FaixaImc.getFaixa(imc, sexo) == resultado 

where: 

imc | sexo || resultado 

18 | Sexo. FEMININO || FaixaImc.ABAIXO 
21 | Sexo. FEMININO || FaixaImc.NORMAL 
27 | Sexo. FEMININO || FaixaImc.ACIMA 

20 | Sexo.MASCULINO || FaixaImc.ABAIXO 
23 | Sexo.MASCULINO || FaixaImc.NORMAL 
28 | Sexo.MASCULINO || FaixaImc.ACIMA 

18.99 | Sexo.FEMININO || FaixaImc.ABAIXO 
19 | Sexo. FEMININO || FaixaImc.NORMAL 
25.99 | Sexo.FEMININO || FaixaImc.NORMAL 
26 | Sexo. FEMININO || FaixaImc.ACIMA 

20.99 | Sexo.MASCULINO || FaixaImc.ABAIXO 
21 | Sexo.MASCULINO || FaixaImc.NORMAL 
26.99 | Sexo.MASCULINO || FaixaImc.NORMAL 
27 | Sexo.MASCULINO || FaixaImc.ACIMA 


} 


Veja como fica mais simples acrescentar novos cenários, apenas 
adicionando novas linhas à tabela do bloco where . 


Testes com falha no Data-Driven Testing 


Vamos supor que a FaixaImc tem um pequeno erro e falhe em alguns 
cenários. Nesse caso, o log de saída do teste terá a mestra 
estrutura que vimos nos capítulos anteriores, como o texto de 
exemplo a seguir. 


FaixaImc.getFaixa(imc, sexo) == resultado 


ABAIXO 19 | | | NORMAL 
| false 
FEMININO 


at unit.br.com.livrospockframework.capituloo5.FaixaImcTest. imc deve 
estar na faixa correta mesmo no limite(FaixaImcTest.groovy:52) 


No log de exemplo, o teste falhou porque, para o cenário da 8º linha 
da tabela de cenários, o resultado esperado para os IMC 19 e sexo 

FEMINIMO era NORMAL, porém o retorno do método getFaixa() foi 

ABAIXO. 


Atenção! A falha na execução de um cenário não impede a 
execução dos seguintes. Por exemplo: se, dentre os 14 cenários, 
os das linhas 1 e 3 da tabela falharem, mesmo assim os cenários 
das linhas 2 e depois de 4 a 14 serão executados normalmente. 


5.3 Descrevendo os testes que falham com 
detalhes dos cenários 


No tópico anterior, vimos que os detalhes do erro em caso de falha 
no teste já são bem úteis. Porém, em situações com muitos cenários 
e/ou com um maior número de valores de entrada e saída, pode ser 
necessário detalhar mais ainda os erros. Para isso existe o recurso 
de Unrolled method do Spock. A seguir, vejamos como transformar 
o exemplo anterior com esse recurso para nos dar mais detalhes 
quando um teste falhar. 


import spock.lang.Unroll; 


@Unroll 

def "IMC #imc deve estar na faixa #resultado para o sexo #sexo"() { 
expect: 
FaixaImc.getFaixa(imc, sexo) == resultado 


resultado 
FaixalImc.ABAIXO 


imc | sexo 
18 | Sexo.FEMININO 
// demais cenários 


|| 
|| 
} 


Usamos a anotação @spock.lang.Unrol1l sobre o método de teste para 
torná-lo um Unrolled method. Assim, os trechos #imc , #resultado € 
#sexo do nome do método serão substituídos pelos valores das 
colunas de mesmo nome na tabela de cenários no log de saída em 
caso de falha de teste. 


Um exemplo de log de saída em caso de falha para o cenário de 
IMC 19 e sexo FEMININO seria como o do texto a seguir. 


IMC 19 deve estar na faixa NORMAL para o sexo FEMININO 
(unit.br.com.livrospockframework.capitulo05.FaixaImcTest) Time elapsed: 
0.007 sec <<< FAILURE! 
org.spockframework.runtime.SpockComparisonFailure: Condition not 
satisfied: 


FaixaImc.getFaixa(imc, sexo) == resultado 
| | | [| 
ABAIXO 19 | | | NORMAL 
| false 
FEMININO 


Note que, antes do texto mais técnico com os valores de objetos e 
métodos da linha de código, agora temos um texto contendo os 
valores explícitos do cenário que falhou. 


O bloco where sempre fica após a execução do teste 


O bloco where sempre fica após os blocos de teste, ou seja, sempre 
após expect OU then , dependendo da opção pelo Four-phase test ou 
Given-When-Then (GWT) (padrões abordados no capítulo 4 - 
Anatomia de um teste Spock). Poderíamos, por exemplo, refazer o 
teste da tabela de IMC no padrão GWT conforme o código a seguir. 


def 'IMC deve estar na faixa correta'() { 
when: 
def calculo = new Object() { 
def getFaixa(imc, sexo) { 
FaixaImc.getFaixa(imc, sexo) 


} 
} 
then: 
calculo.getFaixa(imc, sexo) == resultado 
where: 
imc | sexo || resultado 
18 | Sexo.FEMININO || FaixaImc.ABAIXO 
21 | Sexo.FEMININO || FaixaImc.NORMAL 
27 | Sexo. FEMININO || FaixaImc.ACIMA 


// demais cenários 


} 


No último exemplo, para aproveitar a mesma enum FaixaImc € usar O 
padrão GWT, criamos um objeto a partir de uma classe anônima 
com um método getFaixa() que apenas retorna o resultado do 
método homônimo da enum. Quanto ao teste em si, a diferença foi a 
troca do expect por when + then . Note que aqui também o where é após 
o bloco de teste que, no caso, é O then. 


Conclusão 


Neste capítulo criamos vimos o superútil e versátil recurso de Data- 
Driven Testing do Spock. Vimos como criar um teste de forma 
simples mesmo que seja executado para vários cenários. No 
próximo capítulo, veremos como esperar que a execução de 
métodos lance exceções. 


CAPÍTULO 6 
Exception Conditions - Testes à espera de 
exceções 


Até aqui já falamos sobre os fundamentos do Spock e sobre o 
recurso Data-Driven Testing que facilita a criação de testes para 
componentes que exigem que vários cenários sejam testados. Mas 
há situações, como as que veremos a seguir, nas quais é esperado 
que ocorram uma ou mais exceções. Neste capítulo veremos como 
testar métodos quando esperamos que ocorram exceções com o 
recurso Exception Conditions. Esse mecanismo do Spock permite 
testar se um componente lançou uma exceção, além de verificar os 
detalhes do erro. 


6.1 Às vezes o certo é dar errado 


Vamos continuar com o exemplo do capítulo anterior: o componente 
que dá informações baseadas no IMC. Vamos supor que 
precisemos agora calcular o IMC, algo que não fizemos 
anteriormente. O cálculo do IMC é simples. Veja na fórmula a seguir. 


IMC = peso / altura x altura 


A partir dessa fórmula, poderíamos criar uma calculadora de IMC 
com uma classe simples como a do código a seguir. 


package br.com.livrospockframework.capitulo0o5; 


public class CalculadoraImc { 
public double calcularImc(double peso, double altura) { 
return peso / altura * altura; 


Chamamos a classe de calculadoraImc . Ela possui apenas um 
método, que é público, chamado caicularImc que, ao receber um peso 
e uma altura , retorna o IMC a partir da fórmula que adotamos. 


Já vimos como testar o resultado do método nos capítulos 
anteriores. Mas, e se algo der errado? Aliás, reflita: o que pode dar 
errado nesse cálculo? Ou ainda: esse cálculo deve ser efetuado 
para quaisquer valores de peso €* altura ? 


Vamos supor que algum desenvolvedor fez essas reflexões e 
chegou às seguintes conclusões sobre o método calcularImc() : 


e Ele não pode receber peso com valores menores ou iguais a 0 
(zero). Afinal, seria um peso irreal. 

e Ele não pode receber altura com valores menores ou iguais a 
0 (zero). Afinal, seria uma altura irreal. 


Então, o desenvolvedor fez algumas mudanças no código do 
método calcularImc() para garantir que valores inválidos de peso e 
altura Não provocariam a execução do cálculo e, consequentemente, 
a devolução de um IMC sem sentido. A nova versão do método está 
no código a seguir. 


public double calcularImc(double peso, double altura) { 
if (peso <= 0) { 
throw new IllegalArgumentException("Peso inválido: "+peso); 


} 
if (altura <= 0) { 
throw new IllegalArgumentException("Altura inválida: "+altura); 


} 


return peso / altura * altura; 


} 


Em sua nova versão, o método calcularImc() não retorna o cálculo do 
IMC caso o peso OU altura recebidos sejam menores ou iguais a O. 
Em vez disso, lança uma 111egalargumentException , que é uma 
exceção da biblioteca padrão do Java. 


Blocos try- catch 


Caso o leitor não se sinta seguro com seu conhecimento sobre 
tratamento de exceções e blocos try-catch , segue um breve 
resumo. 


Quando podem ser usados? 


Quando algum método anuncia uma exceção checada em sua 
assinatura. Isso obriga quem o invoca a tratar essa exceção, o que 
pode ser feito com esses blocos. 


Quando algum método anuncia uma exceção não checada em sua 
assinatura, o que não obriga quem o invoca a tratá-la, o 
desenvolvedor pode usar esse bloco apenas se achar necessário. 
Isso costuma ser feito em situações como: registrar a ocorrência da 
exceção em um log de erro; evitar que um bloco de linhas código 
seja interrompido bruscamente; envelopar uma exceção em outra, 
normalmente por uma criada no projeto. 


Como funcionam? 


Dentro do bloco try há uma ou mais linhas que podem lançar 
exceções. Se nenhuma exceção ocorrer, todas as linhas desse 
bloco serão executadas. 


Caso alguma exceção ocorra no bloco try , as linhas de código do 
bloco catch serão executadas. Na declaração do catch devem constar 
uma ou mais classes de exceções e o objeto no qual é instanciada a 
exceção. A esse objeto chamamos de exceção capturada. 
Vejamos o código a seguir. 


try { 
// linha a 
// linha b 

} catch (IOException ex) { 
// linha c 


} 


No código de exemplo, se nenhuma exceção ocorrer no bloco try, 
as linhas a e b serão executadas. Caso contrário, a linha c será 


executada, pois está no bloco catch . 


O bloco catch, se executado, possui à sua disposição na linha c o 
objeto ex (do tipo 10Exception ), que é a exceção capturada. Caso 
fosse necessário tratar mais de uma exceção ao mesmo tempo, 
poderíamos anunciar mais de um tipo de exceção no bloco catch, 
como no próximo exemplo: 


} catch (IOException | NumberFormatException ex) 1 
// linha c 


} 


Outra opção é ter mais de um bloco catch , como no exemplo a 
seguir. 


+ catch (IOException ex1) { 
// linha c 

} catch (NumberFormatException ex2) { 
// linha d 


} 


Nesse último exemplo, caso a exceção que ocorra no bloco try seja 
uma īoException , a linha c seria executada. Caso ocorra uma 
NumberFormatException , a linha d seria executada. 


Como foi dito, isso é apenas um resumo. Para saber mais sobre os 
blocos try-catch e tudo mais que envolve exceções com Java, uma 
ótima referência é o livro da Casa do Código Java SE 8 Programmer 
|- O guia para sua certificação Oracle Certified Associate, de 
Guilherme Silveira e Mário Amaral. 


Para garantir que a execução do método calcularImc() lance uma 
exceção, vamos criar uma classe de teste chamada 
CalculadoraImcTest € USar OS recursos que aprendemos até o 
momento para tentar testar a situação de erro desse método em 
caso de peso inválido. 


package unit.br.com.livrospockframework.capituloos; 


import br.com.livrospockframework.capituloo5.CalculadoraImc 


class CalculadoraImcTest extends Specification { 


def 'lancar exceção com peso invalido'() { 
when: 
boolean houveExcecao 


try { 
new CalculadoraImc().calcularImc(90, 1.70) 
houveExcecao = false 

} catch (IllegalArgumentException e) 1 
houveExcecao = true 


then: 
houveExcecao 


} 


O teste recém-criado passará caso a execução do calcularImc() 
lance uma exceção do tipo 111egalargumentException . Porém ficou um 
código um tanto verboso: tivemos que usar blocos try-catch para a 
montagem do teste. Caso o bloco try chegue ao seu final sem 
exceções, a variável houveExcecao recebe false . Caso uma 
I1legalArgumentException OCOIra, houveExcecao recebe true . O valor de 
houveExcecao é que determina o resultado do teste. 


É em situações como essa, em que precisamos testar se houve 
erro, que podemos usar o recurso Exception Conditions do Spock. 
Veja como faríamos o mesmo teste usando esse recurso no código 
a seguir. 


def 'lancar exceção com peso invalido'() { 
when: 
new CalculadoraImc().calcularImc(9, 1.70) 


then: 
thrown(IllegalArgumentException) 


Aqui usamos o método thrown() da superclasse specification . Esse 
método é uma das formas de usar Exception Conditions. Ele verifica 
se a exceção do argumento foi lançada durante a execução do 
teste. Ao ser executado, esse teste passaria normalmente. 


Mas, vamos supor que ele tivesse sido executado quando a classe 
CalculadoraImc ainda estava na primeira versão apresentada neste 
capítulo. Como não havia a possibilidade de ocorrer uma exceção, 
esse teste falharia e geraria um log como do texto a seguir. 


lancar exceção com peso invalido 
(unit.br.com.livrospockframework.capituloo5.CalculadoraImcTest) Time 
elapsed: 0.001 sec <<< FAILURE! 


org.spockframework.runtime.wWrongExceptionThrownError: Expected exception 
of type 'java.lang.IllegalArgumentException', but no exception was thrown 


Note no log de exemplo que o erro foi que não aconteceu o erro 
esperado na execução do calcularimc() . Não foi lançada uma 
IllegalArgumentException. 


Um detalhe importante: o método thrown só pode estar dentro de 
blocos then . Se estiver dentro de um expect , a classe de testes 
sequer compila. 


6.2 Testando vários cenários de erro 


Um componente pode ter vários cenários que provoquem erro. E é o 
caso de nosso método calcularImc() , que pode lançar exceções para 
valores de peso OU altura inválidos. Para testar os vários cenários, 
poderíamos simplesmente criar vários métodos de teste, um para 
cada cenário. Porém, isso é desnecessário com o Spock, já que é 
possível repetir os blocos when € then para testar diferentes cenários 
que esperam exceções. Vejamos como testar mais de um cenário 


que provoque exceção para valores inválidos de peso no próximo 
código. 
def 'lancar exceção com peso invalido'() { 


when: 
new CalculadoraImc().calcularImc(9, 1.70) 


then: 
thrown(IllegalArgumentException) 


when: 
new CalculadoraImc().calcularImc(-1, 1.70) 


then: 
thrown(IllegalArgumentException) 


6.3 Verificando detalhes das exceções 


Até agora vimos como verificar se uma determinada exceção foi 
lançada com a execução de um método. Mas pode ser necessário 
testar se a exceção que ocorreu possui detalhes desejados. 


Na última versão do método de cálculo de IMC apresentada, as 
exceções continham mensagens específicas para erros de peso € 
altura . Vamos supor que seja necessário garantir que as 
mensagens sejam exatamente aquelas. Poderíamos criar um novo 
método de teste na calculadoraImcTest , como o do código a seguir. 


def 'lancar exceção c/ mensagem correta p/ peso inválido'() { 
when: 
def peso = -1 
new CalculadoraImc().calcularImc(peso, 1.70) 


then: 
def ex = thrown(IllegalArgumentException) 


ex.message == "O peso $peso é inválido" 


} 


Note que a diferença para o que fizemos até agora é que usamos o 
retorno do método thrown() para guardar a exceção lançada no 
objeto ex . Com o ex à disposição, podemos testar quaisquer 
detalhes que precisarmos da exceção. No exemplo, verificamos se a 
mensagem da exceção contém um determinado texto. 


De propósito, testamos uma mensagem diferente da que realmente 
é usada na exceção lançada no método de cálculo do IMC. Ao 
executar o teste, ele falhará e produzirá um log de erro, como o do 
próximo texto. 


lancar exceção c/ mensagem correta p/ peso 
inválido(unit.br.com.livrospockframework.capitulo95.CalculadoraImcTest) 
Time elapsed: 0.015 sec <<< FAILURE! 
org.spockframework.runtime.SpockComparisonFailure: Condition not 
satisfied: 


ex.message == "O peso $peso é inválido” 
| | 
| -1 
false 
14 differences (30% similarity) 
(P--)eso (----- Jinválido(: -1.0) 
(O p)eso (-1 é Jinválido(------ ) 
Peso inválido: -1.0 





java. lang. IllegalArgumentException: Peso inválido: -1.0 


Para que o último teste passe, basta ajustar o bloco then para 
esperar pela mensagem correta, como no próximo código: 


then: 
def ex = thrown(IllegalArgumentException) 
ex.message == "Peso inválido: $fpeso.toDouble())" 


Nos exemplos deste capítulo verificamos o conteúdo da mensagem 
da exceção lançada, mas poderíamos ter testado qualquer outro 
atributo ou retorno de método de ex que fosse necessário. Por 


exemplo, poderíamos verificar a exceção anterior na pilha de 
exceções, por meio do método getcause() . 


Conclusão 


Neste capítulo vimos como testar situações de exceções esperadas 
com o uso de Exception Conditions do Spock. Vimos como criar um 
teste que verifica se determinada exceção foi lançada, bem como 
testar seus detalhes. No próximo capítulo, veremos como criar e 
configurar Mocks. 


CAPÍTULO 7 
Testando com a ajuda de Mocks 


Até aqui já vimos como criar vários tipos de testes com Spock: 
testes simples, testes que exigem vários cenários e testes que 
esperam por exceções. Neste capítulo veremos como trabalhar com 
dublês, que são objetos que imitam o comportamento de 
componentes que dão suporte a um teste, mas que não são seus 
protagonistas. 


7.1 O que são dublês e por que usá-los 


Para a execução de alguns tipos de testes, fica complexo e até 
arriscado usar todos os componentes reais envolvidos na 
funcionalidade a ser testada. Imagine que você precisa testar 
funcionalidades como: um método que exclui centenas de registros 
em um banco de dados; um método que envia centenas de e-mails; 
um método que traz centenas de objetos JSONs de uma REST API. 
Em todos esses exemplos estamos sujeitos a uma série de 
problemas. 


Ou seja, há testes nos quais usar todos os componentes reais 
envolvidos pode torná-los mais complexos do que deveriam. Outro 
problema no uso de certos tipos de componentes é o fato de 
estarem expostos à dependência de fatores externos. Existem 
ainda componentes cujo uso em testes ser até perigoso. São 
exemplos de componentes com uma ou mais dessas características 
aqueles que: 


e Exigem muitas configurações; 
e Exigem muitas dependências; 
e Têm necessidade de estar em uma rede; 


e Têm necessidade de acesso à internet; 

e São afetados pela latência de rede; 

e Têm a necessidade de licença de uso de software; 

e Dependem da disponibilidade de algum serviço externo; 

e Dependem do desempenho de algum serviço externo; 

e Podem afetar dados sensíveis em bases de dados; 

e Podem realizar ações que geram inconvenientes, como o envio 
de excesso de e-mails para clientes reais, por exemplo; 

e Podem levar ao aumento custos financeiros pois podem 
consumir serviços que são tarifados por tempo e/ou volume de 
Uso. 


Porém, imagine que nos exemplos citados no início deste tópico: 


e Os registros não precisam ser realmente excluídos do banco. 
Só é necessário garantir que houve a solicitação para excluí- 
los; 

e Os e-mails não precisam ser realmente enviados. Só é 
necessário garantir que ocorreram as solicitações de envio; 

e Não é necessário obter os JSON realmente da API. Só é 
necessário ter objetos JSONSs na quantidade e no formato 
desejados. 


Note que as funcionalidades que poderiam acrescentar 
complexidade e/ou perigo aos testes não são o alvo dos testes. 
Para situações assim, podemos substituir alguns componentes por 
dublês, que são objetos que imitam outros. 


Existem vários tipos de dublês, sendo os principais dummy , fake, stub , 
spy € mock . Esses termos foram sugeridos por Gerard Meszaros, em 
sua obra xUnit Test Patterns: Refactoring Test Code, de 2007: 
(http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20D 
ummies.html) e também usados por Martin Fowler em um artigo seu 
no mesmo ano 
(https://martinfowler.com/articles/mocksArentStubs.html). 


Tipos de dublês 


Dummy: é o tipo de dublê mais simples. É usado apenas para 
preencher passagens de parâmetros. São valores simples como 
pequenos alfanuméricos, números, uma data qualquer, textos em 
branco ou até valores nulos. 


Fake: esse tipo de dublê é usado principalmente para contornar 
problemas de dependências. São objetos simples, que não guardam 
estado. Um exemplo seria criar uma classe FakeDriver que imita 
uma Driver (um Driver JDBC), possuindo métodos públicos com a 
mesma assinatura. Assim, dispensamos toda uma lista de 
dependências e podemos realizar o teste cujo foco não era o Driver 
JDBC e sim o que acontece após invocar alguma funcionalidade 
dele. Os Fakes sempre apresentam o mesmo comportamento para 
suas funcionalidades. Por exemplo, um objeto Fake de uma classe 
FakeDriver sempre retornaria o mesmo valor em um método 
connect () independentemente dos argumentos usados. Devido à sua 
simplicidade, são normalmente criados manualmente, ou seja, sem 
auxílio de bibliotecas de Mocks. 


Stub: é muito parecido com o Fake. A diferença é que podem ser 
configurados diferentes comportamentos para os métodos conforme 
os argumentos usados. Ou seja, um mesmo objeto Stub pode ter 
diferentes comportamentos para diferentes cenários de teste. São 
normalmente criados com auxílio de alguma biblioteca de Mocks. 


Spy: são dublês que permitem saber detalhes que ocorreram 
durante a execução de seus métodos. Por exemplo, um Driver 
JDBC deveria receber 3 vezes a solicitação para invocar seu 
método para executar instruções SQL caso o método que está 
sendo testado receba uma lista com 6 elementos. Se usarmos um 
Spy para imitar o Driver JDBC, podemos obter dele a informação de 
quantas vezes qualquer um de seus métodos foi executado durante 
um teste. São normalmente criados com auxílio de alguma 
biblioteca de Mocks. 


Mocks: são os dublês mais completos. Permitem a configuração de 
diferentes comportamentos de acordo com as entradas (como um 


Stub) assim como permitem saber quantas vezes seus métodos 
foram executados (como um Spy). São normalmente criados com 
auxílio de alguma biblioteca de Mocks. 


No Spock, não é possível criar dublês que são somente Stub ou 
Spy. Ele cria somente Mocks. Dublês dos tipos Dummy e Fake são 
criados manualmente, sem auxílio do framework e, por esse motivo, 
não são foco deste capítulo. 


7.2 Dependências adicionais para Mocks 


Para que seja possível trabalhar com Mocks no Spock, é necessário 
incluir a dependência de 2 bibliotecas: objenesis € byte-buddy . Elas 
serão usadas de forma transparente pelo Spock. A seguir, o código 
que deve ser incluído no pom.xmi do projeto para adicioná-las. 


<dependency> 
<grouplId>net.bytebuddy</groupId> 
<artifactId>byte-buddy</artifactId> 
<version>1.6.5</version> <!-- ou a versão que precisar --> 
<scope>test</scope> 

</dependency> 

<dependency> 
<groupId>org.objenesis</groupId> 
<artifactId>objenesis</artifactId> 
<version>2.5.1</version> <!-- ou a versão que precisar --> 
<scope>test</scope> 

</dependency> 


A versões dessas dependências podem ser as de que precisar ou 
preferir. A sugestão é deixá-las no escopo test do projeto, para 
evitar seu uso por engano fora dos testes. 


7.3 Configurando retornos de métodos em Mocks 


O tipo de Mock mais simples de que podemos precisar é aquele em 
que apenas programamos os retornos de seus métodos. Imagine 
uma situação em que precisamos invocar métodos de um objeto 
cuja criação é muito difícil de reproduzir usando sua classe real (é 
instanciada via inversão de controle, por exemplo), porém, o que 
realmente precisamos para um teste é apenas usar o retorno de 
alguns de seus métodos. Para situações como essa, é possível criar 
e configurar o retorno de métodos de Mocks. 


Vamos usar como exemplo a mesma Calculadora de IMC dos 
capítulos anteriores. Vamos supor que foi necessário evoluir o 
projeto e foi criada uma interface chamada pedidoImc cuja 
implementação em tempo de execução ocorre por meio de 
mecanismos complexos de reproduzir, como inversão de controle, 
por exemplo. Seu código-fonte está a seguir. 


package br.com.livrospockframework.capitulo9o7.model; 
import br.com.livrospockframework. capitulo9O5.enums.Sexo; 


public interface PedidoImc { 
String getNome(); 
double getPeso(); 
double getAltura(); 
Sexo getSexo(); 
+ 


E, para representar o resultado de um cálculo de IMC, foi criada 
também uma classe, a ResultadoImc , cujo código está a seguir. 


package br.com.livrospockframework.capitulo9o7.model; 


public class ResultadoImc ( 
private String nome; 
private double imc; 
private String condicao; 


public ResultadoImc(String nome, double imc) { 


super(); 


this.nome = nome; 
this.imc = imc; 


// construtor padrão, getters e setters 


} 


O atributo nome é o nome da pessoa de quem foi solicitado o cálculo. 
O imc é o valor do IMC calculado. O condicao é a descrição da 
condição de saúde da pessoa correspondente ao seu IMC. 


As interface e classe recém-criadas agora são usadas na classe 
CalculadoraImc , a mesma dos capítulos anteriores. Observe o método 
verificarCondicaoImc() criado nessa classe. 


import br.com.livrospockframework.capituloo7.model.PedidoImc ; 
import br.com.livrospockframework. capitulo0o7.model.ResultadoImc ; 


// demais imports 


public class CalculadoraImc { 
// mesmo método calcularImc() dos capítulos anteriores 


public ResultadoImc verificarCondicaoImc(PedidoImc pedido) { 
ResultadoImc resultado = new ResultadoImc(); 
resultado. setNome(pedido.getNome()); 


try { 
double imc = this.calcularImc(pedido.getPeso(), 
pedido.getAltura()); 
resultado.setImc(imc); 
resultado.setCondicao( 
FaixaImc.getFaixa(imc, 
pedido.getSexo()).getDescricao()); 
} catch (IllegalArgumentException e) 1 
resultado. setCondicao("Impossível calcular IMC: 
"+e.getMessage()); 


} 


return resultado; 


} 


O método verificarcondicaoImc() recebe um objeto do tipo PedidoImc e 
retorna um objeto do tipo Resultadormc . Esse método preenche o 
atributo nome do resultado com o valor do atributo de mesmo nome 
do pedido. Caso o IMC seja calculado, seu valor é atribuído ao 
atributo imc do resultado e o atributo condicao é preenchido conforme 
a descrição obtida em Faixatmc . Caso o IMC não seja calculado 
devido a valores inválidos de peso ou altura, a condicao recebe um 
texto padrão sobre a impossibilidade do cálculo. 


Vamos então criar nosso primeiro Mock com Spock para podermos 
testar o método calcularImc() da calculadoraImc . Ele será criado na 
classe de teste já existente calculadoraImcTest , como pode ser visto 
no método do código-fonte a seguir. 


import br.com.livrospockframework.capitulo9o7.model.PedidoImc 
import br.com.livrospockframework.capitulo0o7.model.ResultadoImc 
// outros imports 


class CalculadoraImcTest extends Specification ( 


def "deveria ser um homem acima do peso'() { 
given: 
def pedido = Mock(PedidoImc) 


pedido.getNome() >> "Zé Fofinho" 
pedido.getSexo() >> Sexo.MASCULINO 
pedido.getPeso() >> 72 
pedido.getAltura() >> 1.50 


when: 
def resultado = new CalculadoraImc().verificarCondicaoImc(pedido) 


then: 
resultado. imc == 32 
resultado.condicao == FaixaImc.ACIMA.descricao 


// demais testes 


} 


A criação do Mock ocorreu no bloco given , onde usamos o método 
Mock() que vem da superclasse spock.lang.Specification do Spock. 
Esse método exige como argumento um tipo indicando para qual 
classe será criada um dublê. Logo, no código do exemplo, criamos 
um Mock para a interface pedidoImc , que chamamos de pedido . 


Logo após a criação do Mock, programamos os retornos dos 
métodos de que precisaremos em nosso teste. Por meio do 
operador >> configuramos os retornos dos métodos getnome() , 
getSexo() , getPeso() € getaltura() . Se não tivéssemos configurado 
explicitamente os retornos desses 4 métodos, O pedido retornaria 
valores padrões de acordo com os tipos de retorno de cada método. 


O QUE MÉTODOS DE MOCKS RETORNAM? 


Quando acabamos de criar um Mock, podemos invocar todos os 
métodos da classe original. Mas, se não programarmos seus 
retornos, o que eles retornam? Eles retornam valores padrão 
conforme seus tipos. 


Tipos primitivos Métodos com retornos de tipos primitivos 
retornam o valor padrão de cada tipo primitivo conforme define a 
linguagem Java: 


e Para int, short € byte é o; 
e Para long é oL i 
e Para double É 0.0; 
Para float é 0.0f; 
Para char É '\uoooo' i 
Para boolean é false. 


Classes (inclusive Wrappers) Métodos com retorno de classes 
retornam nu11 por padrão. Métodos com retorno de classes 
Wrappers ( Integer , Double , Boolean etc.) também retornam null por 
padrão. 


Vetores e coleções Métodos com retorno de vetores e coleções 
retornam null por padrão, mesmo que se trate de um vetor de 
um tipo primitivo. 


Métodos sem retorno (void) Por padrão, métodos sem retorno 
(retorno void ) são executados sem erro. A execução é 
instantânea, como se o método nem tivesse sido executado. 





Assim, com o Mock criado e configurado, durante a invocação do 
método verificarCondicaoImc() , O argumento do tipo pedidoImc retorna 
os valores programados no Mock do teste. Ao final da execução, 
este método retorna uma instância de ResultadoImc que pode ser 
analisada normalmente no bloco then do teste. 


Só é possível indicar um retorno para métodos dos Mocks? E 
se precisar de algo mais dinâmico? 


Na verdade, o operador >> pode ser usado também para indicar 
todo o corpo do método de um Mock. No código do exemplo 
anterior, poderíamos, por exemplo, ter definido o retorno do método 
que indica o nome a partir do retorno do método que indica o sexo, 
como no código a seguir. 


def 'deveria ser um homem acima do peso'() 1 
given: 
def pedido = Mock(PedidoImc) 


pedido.getNome() >> { 
if (this.getSexo() == Sexo.Masculino) { 
"Zé Fofinho" 
} else { 
"Maria Fofinha" 


// demais código do teste 


Nesse código, indicamos não apenas um valor de retorno do 
método getNome() , mas todo o seu corpo, no qual definimos o retorno 
conforme o que retornar o método getsexo() do próprio Mock. 


Configurando métodos de Mocks para aceitarem qualquer valor 


Imagine a situação em que você precisa configurar o retorno de um 
método que possui um ou mais argumentos. Só que o valor de 
algum dos argumentos (ou todos) não é relevante para o teste ou é 
impossível de prever, ou podem receber qualquer valor. Nesse caso, 
podemos configurar o Spock para determinar o retorno do método 
com um ou mais argumento recebendo qualquer valor válido. 


Vamos supor que a interface PedidoImc possua mais 2 métodos com 
argumentos, como no código a seguir. 


public interface PedidoImc { 
String getNome(String pronomeTratamento) ; 
String getNome(String pronomeTratamento, String apelido); 
// demais métodos 


} 


Para configurar o retorno das 2 novas versões do método getnome() 
sem nos importarmos com os valores dos argumentos, poderíamos 
configurar um Mock de pedidormc usando o operador underline ( _) 
como no código de teste Spock a seguir. 


def pedido = Mock(PedidoImc) 


pedido.getNome(_) >> "Sr. Zé Importante" 

pedido.getNome(_, _) >> "Sr. Zé Imitador, vulgo 'ator'" 
pedido.getNome(_, 'alpinista') >> "Sr. Zé Luiz, vulgo 'alpinista'" 
pedido.getNome('Sr.', _) >> "Sr. Zé Boleiro, vulgo 'messi'" 


Nesse código realizamos 4 configurações de retornos para as 2 
novas versões método getNome() . Foram todas aplicadas no mesmo 
objeto Mock. Os retornos ficaram assim configurados: 


e Na 1º configuração: ao ser invocado com qualquer valor no 
único argumento, retorna "sr. zé Importante". 

e Na 2º configuração: ao ser invocado com quaisquer valores no 
primeiro e segundo argumentos, retorna "sr. zé Imitador, vulgo 
“ator. 

e Na 3º configuração: ao ser invocado com qualquer valor no 
primeiro argumento e 'alpinista' no segundo, retorna "sr. zé 
Luiz, vulgo 'alpinista'”. 

e Na 4º configuração: ao ser invocado com 'sr.' no primeiro 
argumento e qualquer valor no segundo argumento, retorna "sr. 


Zé Boleiro, vulgo 'messi'". 


7.4 Configurando Mocks para lançarem exceções 


Imagine situações em que o comportamento de um componente 
pode lançar exceções em situações complexas de reproduzir a 
qualquer momento, como problemas de rede ou indisponibilidade de 
serviço externo, por exemplo. Para situações como esta, é possível 
configurar um Mock para lançar exceções na invocação de métodos. 


Criando um Mock que lança uma exceção simples 


Vamos supor que você precisa de um componente de envio de e- 
mails. Para facilitar esse tipo de tarefa, você optou por usar a 
biblioteca Apache Commons Email 
(https://commons.apache.org/proper/commons-email/) e criou a 
classe EnvioEmailservice , cujo código-fonte está a seguir. 


package br.com.livrospockframework.capitulo07.services; 


import org.apache.commons.mail.Email; 
import org.apache.commons.mail.EmailException; 


public class EnvioEmailService { 
private Email email; 
private int enviados; 
public EnvioEmailService(Email email) 1 


this.email = email; 


public void enviarEmails(String assunto, String conteudo, List<String> 
destinatarios) throws EmailException { 
this.email.setSubject (assunto); 
this.email.setMsg(conteudo); 
this.email.addTo(destinatarios.toArray (new 
String[destinatarios.size()])); 


this.email.send(); 


this.enviados++; 


// getEnviados() 
} 


A classe EnvioEmailService possui um atributo do tipo 
org.apache.commons .mail.Email que é atribuído no construtor da classe. 
É em objetos dessa classe da Apache Commons Email que são 
configurados os dados de acesso ao servidor de e-mail. 


O método enviarEmails() USa seus argumentos para invocar os 
métodos do atributo de instância email e, caso tudo dê certo, o 
atributo enviados aumenta seu valor em 1. Dentre os métodos 
invocados, o método send() anuncia uma 
org.apache. commons .mail.EmailException. Ao estudar a API da Apache 
Commons Email, verificamos que essa exceção sempre traz o 
motivo do erro. Exemplos: para problemas de autenticação, a causa 
é uma javax.mail.AuthenticationFailedException ; para problemas de 
conexão, a causa é uma com. sun.mail.util.MailConnectException. 
Existem várias outras causas de erro para o envio de e-mails, mas 
vamos usar apenas essas duas em nosso exemplo. Caso o e-mail 
seja enviado em erros, o atributo de instância enviados aumenta seu 
valor em 1. 


Se não fosse possível criar Mocks para configurar o lançamento das 
exceções no envio de e-mail, teríamos que ficar solicitando de fato o 
envio de e-mails. Os possíveis problemas dessa abordagem seriam 
vários: estaríamos sujeitos à latência de rede; poderíamos bloquear 
uma conta ou mesmo cair em uma black list ao tentar muitas 
autenticações sem sucesso; seria complicado simular problemas de 
conexão de rede durante os testes; poderíamos acabar tendo que 
pagar pelo excessivo envio de e-mails, dependendo do contrato com 
o provedor. 


Vamos então criar uma classe de teste chamada 
EnvioEmailServiceTest , Na qual vamos usar Mocks que lançam 
org.apache. commons .mail.EmailException COM à devida causa para evitar 


que, para testar nossa EnvioEmailservice , precisemos enviar e-mails 
de fato. Vejamos o código dessa classe de teste a seguir. 


package unit.br.com.livrospockframework.capituloo7 


import org.apache. commons .mail.Email 
import br.com.livrospockframework.capitulo07.services.EnvioEmailService 
// demais imports 


class EnvioEmailServiceTest extends Specification { 


Email email 
EnvioEmailService service 


def setup() 1 
this.email = Mock(Email) 
this.service = new EnvioEmailService(this.email) 


} 


A parte do código da EnvioEmailserviceTest por enquanto, não possui 
testes. Nela, declaramos dois atributos: o email, do tipo 
org.apache.commons.mail.Email, que será instanciado com um Mock, e o 
service do tipo da classe que queremos testar, a EnvioEmailservice . O 
Mock é criado no método setup() , onde é usado como argumento do 
construtor usado para instanciar O service . Vale lembrar que o 
setup() será invocado sempre antes de cada método de teste. 


Agora vamos criar um teste que espera por exceção ocasionada por 
problema de conexão com o servidor de e-mail. Para isso, vamos 
configurar o Mock para a lançar exceção esperada para que ela 
ocorra quando usamos o service . Vejamos no próximo código. 


// pacote 


import javax.mail.AuthenticationFailedException 
// demais imports 


class EnvioEmailServiceTest extends Specification { 


// atributos e setup() 


def 'deveria lançar erro de autenticação" () 1 
given: 
def msgErro = 'Falha de autenticação! Sorry :(' 


this.email.send() >> { 
throw new EmailException(new 
AuthenticationFailedException(msgErro)) 


} 


when: 
this.service.enviarEmails('assunto', 'conteudo', ['em@t.com']) 


then: 

def ex = thrown(EmailException) 

ex.cause.class == AuthenticationFailedException.class 
ex.cause.message == msgErro 


Ithis.service.enviados 


} 


No bloco given apenas definimos a mensagem de erro que será 
usada no Mock e para posterior comparação com o resultado da 
execução do teste. Em seguida, configuramos nosso Mock, O email 
para que, quando invocar o método send() lance uma EmailException 
cuja causa é uma javax.mail.AuthenticationFailedException . Observe 
que definimos um bloco de código com o operador >> . É que, com 
Spock, podemos definir todo o corpo do método do Mock, e foi isso 
que foi feito no exemplo. 


No bloco when apenas invocamos o método que queremos testar. E 
no bloco then testamos: 


e se foi lançada uma EmailException; 
e se a causa da exceção foi uma authenticationFailedException ; 
e se a mensagem da causa foi a definida no Mock (lá no bloco 


given ); 


e se o atributo enviados continua zerado. 


Ratificando: sem o uso de Mock nosso teste seria mais lento na 
execução (pois estaríamos sujeitos à latência de rede e 
desempenho do servidor de e-mail) além de correr o risco de 
bloquear uma conta devido às falhas de autenticação ou mesmo 
entrar em uma black list do serviço de e-mail. E, com uso de Mock, 
não precisamos configurar a autenticação do objeto do tipo Email, O 
que nos poupou algumas linhas de código. 


Criando um Mock que lança uma exceção com muitos detalhes 


No exemplo anterior, a exceção lançada era bem simples, bastando 
criar uma authenticationFailedException indicando sua mensagem de 
erro. E a mensagem que indicamos acabou se tornando literalmente 
a mensagem da exceção. Porém, algumas exceções não são tão 
simples assim. A seguir, vamos ver como testar outro possível 
problema em nosso serviço de envio de e-mails. 


O outro tipo de exceção que vamos testar agora é a 
com.sun.mail.util.MailConnectException . Diferente da situação do tópico 
anterior, ela exige mais detalhes para ser criada e sua mensagem 
de erro não pode ser definida na criação. Vejamos como criar o 
Mock para essa exceção no método de teste que também ficará na 
EnvioEmailServiceTest , Cujo código está a seguir. 


def 'deveria lançar erro de conexão'() 1 
given: 
def servidor = 'teste.com' 
def porta = 7777 
def timeout = 1 


this.email.send() >> { 
def sce = new SocketConnectException("", null, servidor, porta, 
timeout) 
throw new EmailException(new MailConnectException(sce)) 


when: 
this.service.enviarEmails('assunto', 'conteudo", ['emat.com']) 


then: 
def ex = thrown(EmailException) 
ex.cause.class == MailConnectException.class 


ex.cause.message. contains(servidor) 
ex. cause.message.contains(porta.toString()) 


Ithis.service.enviados 


} 


No bloco given indicamos o servidor, porta e timeout que serão 
usados na criação do Mock do teste. Em seguida, configuramos o 
método send() para lançar uma EmailException na qual definimos que a 
causa é uma com.sun.mail.util.SocketConnectException. Para definir 
essa causa, não poderíamos usar um construtor que apenas define 
a mensagem, pois ele não existe na socketconnectException . 
Tínhamos que definir uma mensagem de detalhe (que não se torna 
a mensagem da exceção, por isso ignoramos), uma causa (que 
ignoramos, por isso null ), um servidor, uma porta e um timeout, 
esses três últimos, definidos há pouco e que poderiam ter quaisquer 
valores válidos. 


No bloco when apenas invocamos o método que queremos testar 
com quaisquer argumentos válidos. E no bloco then testamos: 


e se foi lançada uma EmailException; 

e se a causa da exceção foi uma socketConnectException ; 

e se a mensagem da causa contém o servidor e a porta definidos 
no bloco given. A mensagem da SocketConnectException é bem 
longa, mas contém o servidor e a porta que foram usados na 
tentativa de conexão com o servidor; 

e se o atributo enviados continua zerado. 


7.5 Configurando retornos de métodos 
aninhados em Mocks 


Já vimos como configurar os retornos dos métodos de um Mock. 
Porém, há situações em que precisamos de retornos de métodos de 
objetos que já foram obtidos de retornos de Mocks. Um exemplo 
disso seria se precisássemos salvar os IMCs das pessoas em uma 
tabela de um banco de dados relacional e usássemos JPA. Imagine 
que a tabela para registro do IMC atual das pessoas tivesse sido 
mapeada pela classe Imcatual , cujo código está a seguir. 


package br.com.livrospockframework.capitulo0o7.entity; 
import javax.persistence.Column; 
import javax.persistence.Entity; 


MEntity 
public class ImcAtual { 


(Column (length=50) 
private String nome; 


(Column 
private double imc; 


public ImcAtual(String nome, double imc) 1 
super(); 
this.nome = nome; 
this.imc = imc; 


} 


// construtor padrão, getters e setters 


E, para salvar um único IMC por pessoa, criamos uma outra classe 
chamada Imcatualservice . Ela deve garantir que uma pessoa só 
possua um registro de IMC, sempre com o mesmo valor calculado. 
Seu código está a seguir. 


package br.com.livrospockframework.capitulo07.services; 


import java.sql.SQLException; 


import javax.persistence.EntityManager; 

import javax.persistence.NoResultException; 

import br.com.livrospockframework.capitulo0o7.entity.Imcatual; 
import br.com.livrospockframework. capitulo97.model.ResultadoImc; 


public class ImcAtualService { 


private static final String CONSULTA IMC = 
"SELECT i FROM ImcAtual i WHERE nome = ?0"; 


private EntityManager entityManager; 


private ImcAtual imcExistente(ResultadoImc resultado) { 
try 1 
return this.entityManager 
.createQuery (CONSULTA IMC, ImcAtual.class) 
.setParameter(0, resultado.getNome()) 
.getSingleResult(); 
} catch (NoResultException e) { 
return null; 


public int registrarImc(List<ResultadoImc> resultados) throws 
SQLException ( 


int inseridos = 0; 
for (ResultadoImc resultado : resultados) { 
ImcAtual imcExistente = this.imcExistente(resultado); 
if (imcExistente != null) { 
imcExistente.setImc(resultado.getImc()); 
continue; 
} 
ImcAtual imcAtual = new ImcAtual(resultado.getNome(), 
resultado.getImc()); 
this.entityManager.persist(imcAtual); 
inseridos++; 


return inseridos; 


} 


O método imcExistente() tenta retornar uma instância de Imcatual a 
partir de um nome. Caso nenhum registro seja encontrado, o 
método retorna nu11 . O método registrarImc() retorna o número de 
registros novos inseridos, porém atualiza os existentes. Ele invoca o 
imcExistente() €, caso encontre registro com o nome, apenas atualiza 
seu IMC. Caso contrário, cria um novo registro. 


Essa classe seria fácil de testar não fosse um detalhe: seus 
métodos usam um atributo de instância privado do tipo 
javax.persistence.EntityManager , chamado entityManager . As 
dificuldades surgem devido aos seguintes fatos: 


e Configurar uma Persistence unit do JPA não é simples, pois 
exigiria uma série de dependências e configurações, além de 
tornar nosso teste dependente da disponibilidade e 
desempenho de um banco de dados. Como o objeto do tipo 
EntityManager não é o foco do teste, podemos simplesmente criar 
um Mock dele. 

e No método imcexistente() usamos 3 métodos de forma aninhada 
sobre O entityManager : primeiro createQuery() €, sobre o retorno 
desde, setParameter() €, sobre o retorno deste, getsingleResult() . 
Para conseguirmos testar essa situação, teremos que criar 
vários Mocks e configurar seus retornos para que imitem essa 
chamada aninhada de métodos. 


Vejamos agora como poderia ficar a classe de testes. Seguindo 
nosso padrão, vamos chamá-la de ImcatualserviceTest . Vejamos seu 
código na sequência. Como ele ficaria um tanto grande, vamos 
transcrevê-lo e explicá-lo por partes. 


package unit.br.com.livrospockframework.capituloo7 


import javax.persistence.TypedQuery 
import br.com.livrospockframework. capitulo9O7.entity.ImcAtual 
import br.com.livrospockframework. capitulo0o7.model.ResultadoImc 


import import 
br.com.livrospockframework. capitulo07.services.ImcAtualService 
// demais imports 


class ImcAtualServiceTest extends Specification { 


String nomeEncontrado = 'Zé Cadastrado" 
String nomeNaoEncontrado1 = 'João Não Cadastrado" 
String nomeNaoEncontrado2 = 'Maria Não Cadastrada" 


EntityManager entityManager 
ImcAtualService service 


def setup() { 
this.entityManager = Mock(EntityManager) 


def resultadoEncontrado = Mock(TypedQuery) 
def resultadoNaoEncontrado = Mock(TypedQuery) 
def instrucaoConsulta = Mock(TypedQuery) 


resultadoEncontrado.getSingleResult() >> new ImcAtual(nome: 
this.nomeEncontrado) 


instrucaoConsulta.setParameter (0, this.nomeEncontrado) >> 
resultadoEncontrado 

instrucaoConsulta.setParameter(0, this.nomeNaoEncontrado1) >> 
resultadoNaoEncontrado 

instrucaoConsulta.setParameter(0, this.nomeNaoEncontrado2) >> 
resultadoNaoEncontrado 


this.entityManager.createQuery(ImcAtualService.CONSULTA IMC, 
ImcAtual.class) >> instrucaoConsulta 


this.service = new 
ImcAtualService(entityManager:this.entityManager) 


} 
// métodos de teste 


} 


Neste código temos apenas os atributos de instância, que serão 
usados em todos os testes, e o método setup() que, como vimos 


anteriormente, será executado sempre antes de qualquer outro 
método de teste. Os atributos são: 


e 3 nomes, sendo 1 que será usado para simular situações de 
nome já existente no banco de dados ( nomeEncontrado ) e 2 para 
simular nomes que não estão ( nomeNaoEncontrado1 @ 
nomeNaoEncontrado2 ). 

e 1 objeto do tipo EntityManager que será instanciado por um Mock; 

e 1 objeto do tipo Imcatualservice que será um objeto real (não 
Mock) usado nos testes dessa classe. 


No método setup() configuramos um Mock simples para o 
entityManager € 3 Mocks para objetos do tipo 
javax.persistence.TypedQuery ( resultadoEncontrado , resultadoNaoEncontrado 


€ instrucaoConsulta ). 


Na sequência configuramos os Mocks que serão usados de forma 
aninhada durante os testes: 


e Método getSingleResult() a partir de resultadoEncontrado : retornará 
uma instância de Imcatual com seu nome igual ao valor de 
nomeEncontrado ; 

e Método instrucaoConsulta() , COM 0 e nomeEncontrado COMO 
argumentos, a partir de instrucaocConsulta : retornará o 
resultadoEncontrado ; 

e Método instrucaoConsulta() , COM 0 e nomeNaoEncontradoi COMO 
argumentos, a partir de instrucaocConsulta : retornará o 
resultadoNaoEncontrado ; 

e Método instrucaoConsulta() , COM 0 e nomeNaoEncontrado?2 COMO 
argumentos, a partir de instrucaoConsulta : retornará o 
resultadoNaoEncontrado ; 

e Método createQuery() à partir de entityManager : retornará o 


instrucaoConsulta . 


Não foi necessário indicar o retorno do getsingleRresult() a partir de 
resultadoNaoEncontrado . Como já explicado neste capítulo, métodos de 
Mocks que não retornam primitivos, retornam null por padrão. 


A instrução final no método setup() é instanciar O service € 
preenchendo O Seu entityManager com O Mock do EntityManager recém- 
criado. Caso não sabia como funciona o construtor usado para 
instanciar UM Imcatual € UM Imcatualservice , Veja o item É possível 
atribuir valores de atributos na criação de objetos no Apêndice A 
- Guia de Groovy para desenvolvedores Java. 


Com os Mocks devidamente configurados, podemos testar o método 
privado imcExistente() como no método de teste a seguir. 


def 'deveria retornar null ou o ImcAtual por nome'() { 
expect: 
Ithis.service. imcExistente(this.nomeNaoEncontrado1) 
Ithis.service. imcExistente(this.nomeNaoEncontrado2) 
this.service. imcExistente(this.nomeEncontrado)?.getNome() == 
this.nomeEncontrado 


} 


Como não havia necessidade de nenhum preparo adicional, esse 
método poderia conter apenas o bloco expect . Nesse bloco, 
verificamos se a invocação do método imcExistente() : 


e Com os nomes que não deveriam ser encontrados pelo 
EntityManager retorna null ; 

e Com o nome que deveria ser encontrado pelo EntityManager 
retorna uma instância de Imcatual CUjO nome é igual ao atributo 


nomeEncontrado . 


No próximo teste verificaremos se o método registrarImc() realmente 
só retorna a quantidade de registros inseridos. Vejamos esse teste 
no próximo código-fonte. 


def 'deveria inserir somente se ainda não existe'() { 
when: 
def resultadosE2 = [ 
new ResultadoImc (nome:nomeEncontrado, imc: 25), 
new ResultadoImc (nome:nomeNaoEncontrado1, imc: 29), 
new ResultadoImc (nome:nomeNaoEncontrado2, imc: 35) 


} 


def resultadosE1 = [ 
new ResultadoImc(nome:nomeEncontrado, imc: 25), 
new ResultadoImc(nome:nomeNaoEncontrado1, imc: 29) 


def resultadosE® = [ 
new ResultadoImc(nome:nomeEncontrado, imc: 25) 


this.service.registrarImc(resultadosE2 
this.service.registrarImc(resultadosE1 
this.service.registrarImc(resultadosE® 


No so w 
Il 
Il 
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Nesse teste, preparamos 3 listas de resultadoImc que serão usadas 
nos testes no bloco when : 


resultadosE2 : lista que contém 1 nome que deve ser encontrado 
e 2 que não devem; 

resultadosE1 : lista que contém 1 nome que deve ser encontrado 
e outro que não; 

resultadosEo : lista que contém apenas 1 nome que deve ser 
encontrado. 


No bloco then verificamos se a invocação do método registrarImc() 
retorna: 


e Valor 2 quando invocado com resultadosE2 ; 
e Valor 1 quando invocado com resultadosE1 ; 
e Valor o quando invocado com resultadosEo . 


7.6 Verificando a quantidade de execuções de 
métodos dos Mocks 


Uma das motivações para o uso de Mocks expostas neste capítulo 
foi a de que há situações em que não precisamos que um 
componente faça sua ação real e sim que seja solicitado a fazê-la. 
Mantendo a classe Imcatualservice como exemplo, imagine que 
queremos ter certeza de que o método persist() dO EntityManager dela 
seja invocado uma certa quantidade de vezes durante a execução 
do método registrarImc() . Como os Mocks do Spock também são 
Spies, é possível saber quantas vezes um método de um Mock foi 
executado. 


Não precisamos mexer em nada na Imcatualservice . Basta criarmos 
um novo teste na classe de testes ImcatualserviceTest , que está no 
código-fonte a seguir. 


def 'deveria criar somente como novo por nome'() { 
given: 
def resultados = [ 
new ResultadoImc (nome:nomeEncontrado, imc: 25), 
new ResultadoImc (nome:nomeNaoEncontrado1, imc: 29), 
new ResultadoImc (nome:nomeNaoEncontrado2, imc: 35) 


when: 
this.service.registrarImc(resultados) 


then: 
2 * this.entityManager.persist(.) 


} 


No cenário programado no último método de teste criamos uma lista 
de 3 objetos do tipo ResultadoImc , em que 1 possui um nome já 
cadastrado e 2 não cadastrados. Portanto, o método persist() do 
EntityManager deveria ser invocado 2 vezes quando usamos o método 
registrarImc() Usando essa lista. Nos blocos given € when não há 
novidades: configuração e execução do método de teste, 
respectivamente. 


A grande novidade está no bloco then . A linha que existe nele 
passará no teste se o método persist() for invocado 2 vezes com 


qualquer argumento durante a execução do código do bloco when . 
Isso foi possível porque o Mock entityManager da classe de testes 
sempre é atribuído ao atributo de mesmo nome no objeto service da 
classe de testes no setup() . 


É interessante destacar a peculiaridade e assertividade nos logs do 
Spock caso esse tipo de verificação falhe. Vamos supor que nosso 

teste esperasse (erroneamente) por 1 execução do método persist() 
. Nesse caso, o log de erro ficaria como no log de exemplo a seguir. 


FAILURE! - in 
unit.br.com.livrospockframework. capituloo7. ImcAtualServiceTest 

deveria criar somente como novo por 

nome (unit.br.com.livrospockframework.capitulo9o7.ImcAtualServiceTest) Time 
elapsed: 0.01 sec <<< FAILURE! 

org.spockframework.mock. TooManyInvocationsError: Too many invocations for: 


1 * this.entityManager.persist(.) (2 invocations) 

Matching invocations (ordered by last occurrence): 

1 * 
<EntityManager>.persist(br.com.livrospockframework.capituloo7.entity.ImcAt 
ual@2bfc2f8b) <-- this triggered the error 

1 * 
<EntityManager>.persist(br.com.livrospockframework.capituloo7.entity.ImcAt 
ual061853c7e) 


Note no log que o Spock indica que houve mais invocações do que 
o esperado ("Too many invocations"), quantas invocações ocorreram 
e ainda os objetos envolvidos em cada execução. Caso a classe 
ImcAtual tivesse sobrescrito O tostring() padrão do Java, o log 
poderia ter ficado ainda mais esclarecedor, podendo indicar, por 
exemplo, atributos dos objetos usados como argumento. 


Conclusão 


Neste capítulo, vimos como criar e configurar Mocks com Spock 
para imitar o comportamento de componentes complexos e/ou 
perigosos que não são objetos do teste. No próximo capítulo, 
veremos como testar REST APIs com o Spock framework. 


CAPÍTULO 8 
Testando RESTful APIs 


Até aqui já vimos como criar vários tipos de testes e como trabalhar 
com dublês no Spock. Neste capítulo veremos como criar testes 
para RESTful APIs que são a tecnologia mais usada atualmente na 
integração de sistemas. 


8.1 O que são RESTful APIs e a importância de 
serem bem testadas 


Esta é uma breve introdução para o leitor que possui pouco ou 
nenhum conhecimento sobre essa tecnologia. 


O REST (REpresentational State Transfer) é um estilo arquitetural 
que usa HTTP ou HTTPS como protocolo de comunicação. Foi 
proposto em 2000, na tese de doutorado de Roy Fielding, que, aliás, 
também é um dos pais do HTTP. 


Quando uma API é criada adotando-se REST, dizemos que se trata 
de uma RESTful API. Porém, é muito comum vermos o termo REST 
API para o mesmo conceito. 


Até meados de 2011, a arquitetura mais usada no mundo para 
implementar APIs era SOAP, mas desde então, REST passou a ser 
mais adotada. Ross Mason, fundador da MuleSoft escreveu um 
artigo falando sobre o fato de REST ter ultrapassado SOAP na 
integração de sistemas (vide em https://www.infog.com/articles/rest- 
soap). Ao recorrermos ao Google Trends, veremos que o interesse 
ao longo do tempo sobre REST (termo de computação) ultrapassou 
o de SOAP (termo de computação) exatamente em junho de 2011 e 
continuou crescendo, conforme a figura a seguir. 
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Figura 8.1: Pesquisas sobre REST x SOAP segundo o Google Trends. Fonte: Google 
Trends. 


PARA SABER MAIS SOBRE REST 


Caso o leitor queira se aprofundar nos conceitos e tecnologias 
de implementação de REST, há três livros da Casa do Código 
que abordam essa tecnologia: 


e REST - Construa API's inteligentes de maneira simples, de 
Alexandre Saudate; 

e Web Services REST com ASP .NET Web API e Windows 
Azure, de Paulo Siécola e 

e Construindo APIs REST com Node.js, de Caio Ribeiro 
Pereira. 





Todas as principais plataformas de desenvolvimento da atualidade 
(Java, .Net, Python, JavaScript/Node.js, Ruby, Go etc.) possuem 
frameworks e/ou bibliotecas para a implementação de RESTful 
APIs. E, se olharmos as grandes empresas de tecnologia como: 
Google, Amazon, Microsoft, IBM, Facebook, operadoras de cartão 
de crédito etc. todas oferecem uma coleção de RESTful APIs para o 
consumo de seus serviços. 


Isso tudo demonstra que, conforme Ross Mason antecipou em 
2011, essa é a abordagem mais usada atualmente na integração de 
sistemas. Assim, é muito provável que você tenha que escrever 
testes para alguma RESTful API interna e/ou de algum fornecedor. 
E caso você ou sua empresa tenha criado uma API, é imperativo 
que ela esteja bem testada para evitar que os que a consomem não 


tenham surpresas desagradáveis, como respostas em formato 
inesperado ou Endpoints com endereço alterado de uma hora para 
outra, por exemplo. 


Uma RESTful API pode ser implementada em praticamente 
qualquer linguagem de programação moderna. Porém, 
independentemente da plataforma de desenvolvimento usada na 
criação trata-se de um serviço que usa o HTTP/HTTPS para enviar 
requisições (ou solicitações) e receber respostas. 


Requisições HTTP 


As requisições HTTP são usadas para que um cliente (ou 
consumidor) inicie uma comunicação com uma RESTful API. Uma 
requisição HTTP é composta basicamente de: 


Método: é um verbo que indica a natureza da chamada. Os 
métodos (ou métodos) HTTP mais usados em RESTful APIS são: 


e GET - Usado para recuperar um ou mais recursos; 

e post - Usado para a criação de um recurso; 

e pur - Usado para a atualização de um recurso; 

e PATCH - Parecido com o pur , mas indicado quando a atualização 
de um recurso é parcial; 

e DELETE - Usado para excluir um recurso. 


Existem ainda vários outros métodos HTTP. Maiores detalhes nas 
páginas sobre métodos HTTP da especificação oficial do HTTP 1.1: 
https://tools.ietf.org/html/rfc7231Hsection-4 e 
https://tools.ietf.org/html/rfco 7 89Hsection-2. 


Parâmetros: um ou mais dados no formado agrupados na forma de 
chave x valor. São usados para detalhar a operação indicada no 
método. Por exemplo, em uma chamada com cer, os parâmetros 
podem servir para indicar os campos e valores envolvidos no filtro 
de uma consulta. 


Cabeçalhos: são muito parecidos com parâmetros, também sendo 
enviados agrupados em chave x valor. A diferença é que aqui são 
enviados dados que não possuem relação direta com a requisição. 
É muito comum serem usados para enviar as credenciais de acesso 
à API e o tipo de dado que está sendo enviado no corpo. Os 
cabeçalhos mais comuns são listados e descritos no Mozilla 
Developers Network (https://developer.mozilla.org/en- 
US/docs/Web/HTTP/Headers). 


Corpo: é o conteúdo da requisição. Esse conteúdo pode ser um 
texto simples, um JSON, um XML ou até mesmo um conteúdo 
binário (PDF, ZIP etc.). Quando é enviado um corpo, o ideal é que 
também seja enviado um cabeçalho chamado Content-type. Alguns 
dos valores mais comuns para esse cabeçalho são: application/json 
(conteúdo JSON), text/xml (conteúdo XML) e application/octet- 
stream (conteúdo binário). 


IMPORTANTE: nem todos os métodos HTTP permitem o envio 


de um corpo. Dos citados aqui, apenas PosT , PUT € PATCH 
permitem. 





Respostas HTTP 


As respostas HTTP são usadas pela RESTful API para devolver o 
resultado de uma requisição HTTP para um cliente. Uma resposta 
HTTP é composta basicamente de: 


Status: é um código numérico que indica o resultado geral da 
resposta. Existem vários códigos, divididos em famílias, sendo que 
as mais usadas em RESTful APIs são: 


e 2xx - Códigos de status que indicam que a requisição foi 
processada com sucesso. Dentre os comuns estão: 200 - Ok 
(indica que deu tudo certo), 201 - Created (indica que um 
recurso foi criado com sucesso) e 202 - Accepted (indica que a 


requisição foi aceita mas que seu processamento completo será 
feito paralelamente); 

e 4xx - Códigos de status que indicam que a requisição foi feita 
com algo errado, ou seja, que o cliente não fez a requisição 
como deveria. Dentre os comuns estão: 400 - Bad request 
(indica que alguma coisa nos parâmetros e/ou corpo da 
requisição está errada), 401 - Unauthorized (indica que era 
necessária alguma credencial de acesso, não fornecida), 403 - 
Forbidden (indica que um recurso não é permitido mesmo com 
as credenciais de acesso fornecidas) e 404 - Not found (indica 
que o recurso solicitado não existe); 

e 5xx - Códigos de status que indicam que a requisição não pode 
ser processada por problema no serviço. Dentre os comuns 
estão: 500 - Internal server error (indica que alguma ocorreu 
algum erro não tratado no serviço) e 503 - Service unavailable 
(indica que o serviço está praticamente fora, só conseguindo 
responder para informar que está indisponível). 


Existem ainda vários outros status de resposta HTTP. Uma lista 
completa pode ser obtida no Mozilla Developers Network 
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Status). 


Cabeçalhos: Valores agrupados em chave x valor que descrevem 
detalhes da resposta e do corpo, caso este esteja presente. 


Corpo: é o conteúdo da resposta. Esse conteúdo pode ser um texto 
simples, um JSON, um XML ou até mesmo um conteúdo binário 
(PDF, ZIP etc.). Quando há um corpo na resposta, o ideal é que 
também seja enviado um cabeçalho chamado Content-type. 
Alguns dos valores mais comuns para esse cabeçalho são: 
application/son (conteúdo JSON), text/xml (conteúdo XML) e 
image/jpeg (imagem). 


Endpoints 


Cada operação disponível em uma API é chamada de Endpoint. É 
para eles que enviamos as requisições HTTP e é deles que 


esperamos as respostas HTTP. Exemplos simples de Endpoint: uma 
API para a realização das operações básicas da aritmética deveria 
ter pelo menos 4 Endpoints: adição, subtração, multiplicação e 
divisão. 


Clientes de uma RESTful API 


Como o único requisito para consumir uma RESTful API é uma 
conexão HTTP/HTTPS, clientes desse tipo de serviço podem ser 
uma simples página HTML, um programa desktop, um aplicativo de 
smartphone ou até mesmo um processo em um sistema 
operacional. O cliente não tem a menor ideia de qual plataforma foi 
usada para desenvolver a API e pode ter sido criado em qualquer 
linguagem capaz de implementar um cliente HTTP. Esse modelo de 
comunicação está representado na figura a seguir. 


RESTful API 


| t 


Protocolo HTTP/HTTPS 












Figura 8.2: RESTful APi comunicando-se com seus clientes por meio do HTTP. 


Como Groovy e Java permitem a criação de clientes HTTP/HTTPS, 
é possível criar testes para RESTful APIs com o Spock framework. 
E o que faremos a seguir. 


8.2 Documentação da API de Cálculo e Banco de 
IMC 


Vamos testar uma API de cálculo de IMC que armazena e permite 
excluir os cálculos solicitados. Ela possui 4 (quatro) Endpoints, 
conforme mostra a figura a seguir. 


























| /imcs Realizar um novo Cálculo e armazenar resultado no histórico de IMCs 3 
sm | /imcs/{id} Recuperar um registro de IMC 3 
em | /imes Recuperar registros de IMC 5 

EE /imcs/(petIdj Excluir um registro de IMC E) 


Figura 8.3: Endpoints da API de Cálculo e Banco de IMC. 


Vale lembrar de que não é nosso foco criar uma RESTful API, 
vamos apenas descrever a API que será testada. Vejamos agora 
uma breve descrição das entradas e saídas de cada Endpoint. 
Essas informações são necessárias para guiar nossos testes. 


Respostas comuns a todos os Endpoints 


Resposta com status 401 - Unauthorized 
Caso a chave de API (Cabeçalho x-api-key ) não seja enviada. 
Resposta com status 403 - Forbidden 


Caso a chave de API (Cabeçalho x-api-key ) tenha sido enviada, 
porém inválida. Na API de nosso teste, a chave válida tem o valor 
chave-valida . 


Resposta com status 400 - Bad request 





Em caso de algo errado nos parâmetros e/ou corpo da requisição. 
Resposta com status 405 - Method not allowed 


Em caso de URL, parâmetros e cabeçalhos válidos, mas método 
HTTP inválido. 


Endpoint post /imcs 
Requisi ão 


Na tabela a seguir, estão os dados que devem ser enviados na 
requisição para este Endpoint. 


Tipo de os aa : 
Nome Canal Aado Obrigatório Descriç 
JSON cc 
parâmet 
JSON da Corpo da JSON S necessá 
requisição requisição para o 
cálculo c 
IMC 
Chave d 
x-api-key Cabeçalho Alfanumérico S autoriza 
de uso d 
API 
content-type: application/json 
JSON da requisição: 
{ 
"nome": "?" (Alfanumérico. Obrigatório), 


"peso": ? (Real. Obrigatório), 
"altura": ? (Real. Obrigatório), 
"sexo": "?" (Alfanumérico, apenas "MASCULINO" ou "FEMININO". 


Obrigatório) 


} 
Resposta com status 201 - Created 


Quando o JSON enviado na requisição estava válido e o cálculo foi 
feito e registrado com sucesso. Nesse caso, o cabeçalho location 
deve estar presente e contendo uma URL que permite recuperar o 
registro recém-criado na API. 


content-type: application/json 


location: como houve a criação de um recurso que ficará disponível 
em outro Endpoint, esse cabeçalho retorna a URL para acessá-lo 
(vide a explicação do GET /imc/{id} ). Exemplo de valor que pode 
chegar nesse cabeçalho: http://hostname ou IP e porta/imcs/12, onde 
12 seria o identificador do cálculo de IMC recém-criado na API. 


JSON de resposta: 
{ 


"id": ? (Inteiro), 

"imc": ? (Real), 

"nome": "?" (Alfanumérico), 
"condicao": "?" (Alfanumérico) 


} 


Resposta com status 400 - Bad request Quando o JSON enviado 
na requisição estiver inválido. 


Endpoint GET /imc/{id} 
Requisi ão 


Na tabela a seguir, estão os dados que devem ser enviados na 
requisição para este Endpoint. 


Tipo de 


Nome Canal Aado 


Obrigatório Descrição 


Idantificadar 


Nome Panal Intépo de Obrigatório 
dado 


x-api- 


Key Cabeçalho Alfanumérico S 


Resposta com status 200 - OK 
Quando o registro for encontrado com sucesso. 
content-type: application/json 
{ 
"id": ? (Inteiro), 
"imc": ? (Real), 
"nome": "?" (Alfanumérico), 


"condicao": "?" (Alfanumérico) 


} 

Resposta com status 404 - Not found 

Quando a busca não encontra o registro solicitado. 
Endpoint GET /imcs 


Requisi ão 


TRANSIT TUITINSCANA I 


dogal ão 


solicitado 


Chave de 
autorização 
de uso da 
API 


Na tabela a seguir, estão os dados que devem ser enviados na 


requisição para este Endpoint. 


Tipo de 


dado Obrigatório 


Nome Canal 


apartir Query Real N 


Descrição 


Filtrar IMCs 
com 


valores a 
nartir da 


par LIL aw 


Tipo de 


Nome Canal ia Obrigatório  Beserigão 

ate Query Real N com 
valores até 
Chave de 

Ada Cabeçalho Alfanumérico S o j 
API 


Resposta com status 200 - OK 
Quando a solicitação encontrou pelo menos 1 registro. 
content-type: application/json 
JSON de resposta: 
[ 
{ 
"id": ? (Inteiro), 
"imc": ? (Real), 
"nome": "?" (Alfanumérico), 


"condicao": "?" (Alfanumérico) 


>, 
| DP 
Resposta com status 204 - No content 
Quando a busca não traz nenhum resultado. 
Endpoint DELETE /imcs/{id} 
Requisi ão 


Na tabela a seguir, estão os dados que devem ser enviados na 
requisição para este Endpoint. 


Tibo de E 


Nome Canal Obrigatório Descrição 


Nome Canal Menag Obrigatório Descrição 
dado Identificador 
id Path Inteiro S do cálculo a 
ser excluído 
Chave de 
x-api- n autorização 
key Cabeçalho Alfanumérico S densas 
API 


Resposta com status 200 - Ok 
Quando o registro solicitado foi excluído com sucesso. 
Resposta com status 404 - Not found 


Quando o registro indicado para a exclusão não existe. 


8.3 Preparando o projeto para testes de REST 
APIs com o HTTP Client Framework For Groovy 


Para facilitar o teste de REST APIs, é indicado o uso de alguma 
biblioteca que facilite o consumo desse tipo de serviço. Como 
estamos usando Groovy como linguagem principal, optamos por 
usar a biblioteca HTTP Client Framework For Groovy. Basta 
adicioná-la como dependência no projeto informando seu groupld 
org.codehaus.groovy.modules.http-builder € Seu artifactld http-builder . 
Assim, sua dependência Maven ficaria como no código a seguir. 


<dependency> 
<groupId>org.codehaus.groovy.modules.http-builder</groupId> 


<artifactId>http-builder</artifactId> 
<version>0.7.1</version> 
</dependency> 


Com essa dependência configurada, vejamos agora como 
poderíamos testar os 4 Endpoints descritos. 


8.4 Testando o Endpoint POST /imcs 


Vamos criar uma classe de testes cnamada ImcapiPostTest e testar as 
situações de requisição perfeita e com problemas no JSON enviado, 
de método HTTP inválido e de chave de API não enviada ou 
inválida. 


Antes da criação dos testes, vamos definir alguns atributos e 
métodos para facilitar a execução de todos os testes planejados. A 
seguir os atributos de instância de nossa classe de teste. 


RESTClient cliente 
def urlBase = "http://localhost:8080' 
def uriEndpoint = '/imcs/calculo' 


O objeto cliente dO tipo groovyx.net.http.RESTClient será usado em 
todos os testes para enviar as requisições e receber as respostas 
dos Endpoints da API. Os atributos utlBase € urlEndpoint serão 
usados no envio das requisições realizadas durante os testes. 


Os métodos que criamos para auxiliar nos testes estão a seguir. 


private def criarPedido() { 
[nome:'Ze Magrinho', altura:1.75, peso: 71, sexo: 'MASCULINO'] 


private def criarHeader() { 
['x-api-key' : 'chave-valida'] 


def setup() 1 
this.cliente = new RESTClient(this.urlBase, ContentType.JSON) 
} 


O método criarPedido() retorna um mapa que será usado para criar o 
JSON de requisição em quase todos os testes da classe. O método 
criarHeader() retorna um mapa que será usado para atribuir o valor 
do cabeçalho de requisição x-api-key em quase todos os testes da 
classe. Ambos são privados para eliminar a possibilidade de serem 
executados como métodos de teste. 


O método setup() é usado para instanciar O cliente informando sua 
URL base e o Content-type padrão usado das requisições e 
respostas. Vale lembrar de que o setup() é invocado sempre antes 
de cada teste conforme vimos no capítulo 4. Anatomia de um teste 
Spock. 


Testando uma requisição sem erros 


Vamos criar um teste na classe ImcapiPostTest que faz uma requisição 
sem erros e que verifica se a resposta está conforme o esperado 
para esse tipo de requisição. Vejamos esse teste a seguir: 


package unit.br.com.livrospockframework.capituloos 
import org.apache.http.HttpResponse 
import org.apache.http.HttpStatus 
import org.apache.http.client.HttpResponseException 
import groovyx.net.http.ContentType 
import groovyx.net.http.RESTClient 
class ImcApiPostTest extends Specification { 
// atributos de instância 


// métodos setup() e privados 


def "deveria calcular e registrar IMC'() { 
given: 


def pedido = this.criarPedido() 


when: 

HttpResponse response = this.cliente.post(path: this.uriEndpoint, 
headers: this.criarHeader(), 
body: pedido) 


then: 'Validando os cabeçalhos da resposta' 
response.status == HttpStatus.SC CREATED 


response. getEntity().contentType.value.startsWith(ContentType.JSON.toStrin 
g()) 


response.cabeçalhos.location.toURL().path.split("/").last().toInteger() 


and: 'Validando o corpo da resposta' 
response.data.size() == 

response.data.id instanceof Number 
response.data.nome == pedido .nome 
response.data.imc instanceof Number 
response.data.condicao instanceof String 


} 


No bloco given instanciamos o mapa pedido que será usado na 
requisição e na verificação do resultado do teste. No bloco when , 
Usamos o cliente para enviar uma requisição com o método HTTP 
post para O Endpoint post /imcs . O mapa pedido usado no atributo body 
será convertido em um JSON para o envio da requisição. O atributo 
headers recebe o mapa criado no método criarHeader() , que contém a 
chave de API válida para a chamada de qualquer Endpoint da API. 
Armazenamos o resultado da requisição no objeto response do tipo 
org.apache.http.HttpResponse . 


Usamos o bloco then para validar somente os cabeçalhos da 
resposta recebida pelo Endpoint. Primeiro validamos se o status que 
chegou foi 201 (Created) . Em seguida, verificamos se O content-type 
da resposta foi application/json . Por fim, verificamos duas coisas de 
uma só vez na terceira linha: ao tentar usar o método tourL() no 
cabeçalho location , acabamos validando se o conteúdo desse 


cabeçalho é uma URL válida. Caso não seja, a invocação desse 
método lançará uma exceção. Logo em seguida, tentamos 
recuperar a última parte a URI da URL nesse cabeçalho e tentamos 
converter em um número inteiro por meio do método toInteger() . 
Caso a URL não termine com um inteiro válido, como indicado na 
documentação, essa linha lançará uma exceção. 


No bloco and verificamos se o JSON do corpo da resposta está 
conforme a documentação. Primeiro testamos se o JSON que 
chegou contém 4 (quatro) atributos. Em seguida, verificamos se o 
atributo id existe e é um valor numérico. Depois, verificamos se o 
atributo nome existe e se é igual ao nome enviado na requisição (no 
objeto pedido ). Em seguida, verificamos se o atributo imc existe e é 
um valor numérico. Por fim, verificamos se o atributo condicao existe 
e é um valor alfanumérico. 


Testando uma requisição com problemas no envio 


Vamos criar agora um teste que realiza uma requisição 
propositalmente mal feita para o Endpoint post /imcs para verificar se 
a resposta está conforme prometido na documentação. A seguir o 
código do método desse teste. 


def 'deveria receber 400 ao tentar criar IMC com JSON ausente ou 
inválido'() { 

when: "Requisição sem JSON no corpo" 

this.cliente.post(path: this.uriEndpoint, headers: this.criarHeader()) 


then: 
HttpResponseException ex = thrown(HttpResponseException) 
ex. statusCode == HttpStatus.SC BAD REQUEST 


when: 'Requisição com JSON inválido" 
this.cliente.post(path: this.uriEndpoint, 
cabeçalhos : ['x-api-key' : 'chave-valida'], 
body: [nome:888, altura: 'toma', peso: 'olha', sexo: 1]) 


then: 
ex = thrown(HttpResponseException) 


ex. statusCode == HttpStatus.SC BAD REQUEST 
} 


Note que há dois pares de blocos when / then . Fizemos isso para 
testar 2 cenários que podem levar a erros com status 400 (Bad 


request) . 


No primeiro bloco when , usamos O cliente para enviar uma requisição 
com o método post para o Endpoint post /imcs de forma muito 
parecida com a que fizemos no método de teste anterior. A 
diferença é que não enviamos nenhum corpo na requisição. Note 
que não há o atributo body no método post() do cliente . 


Usamos o primeiro bloco then para verificar se a resposta chegará 
com o status 400 (Bad request) . Note que usamos a verificação de 
exceções do Spock (já estudada no capítulo 6. Exception 
Conditions - Testes à espera de exceções). Quando enviamos 
uma requisição usando o HTTP Client Framework For Groovy e o 
status de resposta não é da família 2xx (status de sucesso) Nem 3xx 
(redirecionamento) É lançada uma exceção do tipo 
org.apache.http.client.HttpResponseException QUE contém um atributo 
statusCode que indica o status que o servidor enviou na resposta. 


No segundo bloco when , usamos O cliente para enviar uma 
requisição com o método post para o Endpoint post /imcs com um 
JSON bem diferente do esperado (veja o mapa estranho que 
usamos no atributo body do método post() do cliente ). 


Então, no segundo bloco then fizemos a mesma verificação do 
primeiro, ou seja, se a resposta chegará com o status 400 (Bad 


request). 
Testando uma requisição usando um método HTTP errado 


Vamos criar agora um teste que realiza uma requisição que 
propositalmente usa um método HTTP inválido para verificar se a 
resposta está conforme a documentação. A seguir o código do 
método desse teste. 


def 'deveria receber 405 ao tentar usar PUT ao invés de POST no cálculo de 
IMC () { 

when: 

this.cliente.put(path: this.uriEndpoint, headers: this.criarHeader(), 
body: this.criarPedido()) 


then: 
HttpResponseException ex = thrown(HttpResponseException) 
ex. statusCode == HttpStatus.SC METHOD NOT ALLOWED 


} 


No bloco when , usamos O cliente para enviar uma requisição com o 
método pur para a URI /imcs da API. O JSON e os cabeçalhos estão 
corretos, mas não era esperado o uso do método pur . 


No bloco then apenas verificamos se a resposta chegará com o 
status 405 (Not allowed) . 


Testando uma requisição sem enviar a chave da API 


Vamos criar agora um teste que realiza uma requisição que 
propositalmente não envia a chave da API necessária para todos os 
Endpoints da API. A seguir o código do método desse teste. 


def 'deveria receber 401 ao tentar calcular IMC sem informar a chave da 
API'() { 

when: 

this.cliente.post(path: this.uriEndpoint, body: this.criarPedido()) 


then: 
HttpResponseException ex = thrown(HttpResponseException) 
ex. statusCode == HttpStatus.SC UNAUTHORIZED 


} 


No bloco when , usamos oO cliente para enviar uma requisição com o 
método post para a URI /imcs da API. O JSON está perfeito, mas não 
enviamos nenhum cabeçalho (note a ausência do atributo headers ), 
portanto, não enviamos a chave da API na chamada do Endpoint. 


No bloco then apenas verificamos se a resposta chegará com o 
status 401 (Unauthorized) . 


Testando uma requisição que envia uma chave de API inválida 


Vamos criar agora um teste que realiza uma requisição que não 
envia uma chave da API propositalmente inválida. A seguir o código 
do método desse teste. 


def 'deveria receber 403 ao tentar calcular IMC informando uma chave da 
API inválida'() { 


when: 

this.cliente.post(path: this.uriEndpoint, 
cabeçalhos : ['x-api-key' : 'chave-INVALIDA'], 
body: this.criarPedido()) 

then: 


HttpResponseException ex = thrown(HttpResponseException) 
ex. statusCode == HttpStatus.SC FORBIDDEN 


} 


No bloco when , usamos O cliente para enviar uma requisição com o 
método rost para a URI /imcs da API. O JSON está perfeito e 
enviamos uma chave de API, porém não uma válida. 


No bloco then apenas verificamos se a resposta chegará com o 
status 403 (Forbidden). 


8.5 Testando o Endpoint GET /imcs/fid) 


Para testar o Endpoint ceT /imcs/{ia} , vamos criar a classe de testes 
ImcApiGetUmTest , Que é muito parecida com a ImcapiPostTest . Os 
métodos criarHeader() € setup() podem ser idênticos. A diferença é 
que não existe o método criarPedido() e o atributo uriEndpoint possui 
outro valor. Portanto, o início dessa classe fica como no código a 
seguir. 


package unit.br.com.livrospockframework.capituloos 
// mesmos imports da ImcApiPostTest 
class ImcApiGetUmTest extends Specification { 


def uriEndpoint = '/imcs/1' 
// demais atributos de instância e métodos criarHeader() e setup() 
idênticos aos da ImcApiPostTest 


O atributo uriEndpoint é uma URI que indica que queremos recuperar 
o cálculo de IMC de identificador 1 . 


Testando uma requisição sem erros 


Vamos criar um teste na classe ImcapiGetumTest que faz uma 
requisição sem erros e que verifica se a resposta está conforme o 
esperado para esse tipo de requisição. Vejamos esse teste a seguir: 


def 'deveria recuperar um IMC'() { 


when: 
HttpResponse response = this.cliente.get(path: this.uriEndpoint, 
headers: this.criarHeader()) 


then: 'Validando os cabeçalhos da resposta" 
response.status == HttpStatus.SC OK 


response. getEntity().contentType.value.startsWith(ContentType.JSON.toStrin 
8()); 


and: 'Validando o corpo da resposta' 

response.data.size() == 

response.data.id == this.uriEndpoint.split('/').last().toInteger() 
response.data.nome instanceof String 

response.data. imc instanceof Number 

response.data.condicao instanceof String 


No bloco when , usamos oO cliente para enviar uma requisição com o 
método HTTP cer para o Endpoint ET /imcs/Lid) . O atributo headers 
recebe o mapa criado no método criarHeader() , que contém a chave 
de API válida para a chamada de qualquer Endpoint da API. 
Armazenamos o resultado da requisição no objeto response do tipo 
org.apache.http.HttpResponse . 


Usamos o bloco then para validar somente os cabeçalhos da 
resposta recebida pelo Endpoint. Primeiro validamos se o status que 
chegou foi 220 (ok) . Em seguida, verificamos se O Content-type da 
resposta foi application/json. 


No bloco and verificamos se o JSON do corpo da resposta está 
conforme a documentação. Primeiro testamos se o JSON que 
chegou contém 4 (quatro) atributos. Em seguida, verificamos se o 
atributo ida é o mesmo número da parte final da uriEndpoint . Depois, 
verificamos se o atributo nome existe e é um valor alfanumérico. Em 
seguida, verificamos se o atributo imc existe e é um valor numérico. 
Por fim, verificamos se o atributo condicao existe e é um valor 
alfanumérico. 


Testando uma requisição informando identificador inválido 


Vamos criar agora um teste que realiza uma requisição com 
identificador propositalmente inexistente para o Endpoint cer 
/imcs/{id} para verificar se a resposta está conforme a 
documentação. A seguir o código do método desse teste. 


def 'deveria receber 404 ao tentar recuperar um IMC informando um 
identificador inexistente'() { 

when: 

this.cliente.get(path: '/imcs/-19', headers: this.criarHeader()) 


then: 
HttpResponseException ex = thrown(HttpResponseException) 
ex. statusCode == HttpStatus.SC NOT FOUND 


No bloco when , usamos oO cliente para enviar uma requisição com o 
método cer para o Endpoint cet /imcs/{id} . Como identificador 
usamos um número negativo, e números negativos não costumam 
ser usados como identificadores de recursos em APIs. Com isso 
esperamos que a resposta seja de status 404, conforme 
especificado. 


Usamos o bloco then apenas para verificar se a resposta chegará 
com o status 404 (Not found). 


Testando uma requisição sem enviar a chave da API 


Vamos criar agora um teste que realiza uma requisição que 
propositalmente não envia a chave da API necessária para todos os 
Endpoints da API. A seguir o código do método desse teste. 


def “deveria receber 401 ao tentar recuperar um IMC sem informar a chave 
da API'() { 

when: 

this.cliente.get(path: this.uriEndpoint) 


then: 
HttpResponseException ex = thrown(HttpResponseException) 
ex. statusCode == HttpStatus.SC UNAUTHORIZED 


} 


No bloco when , usamos O cliente para enviar uma requisição com o 
método cET para a URI /imcs da API. O JSON está perfeito, mas não 
enviamos nenhum cabeçalho (note a ausência do atributo headers ), 
portanto, não enviamos a chave da API na chamada do Endpoint. 


No bloco then apenas verificamos se a resposta chegará com o 
status 401 (Unauthorized) . 


Testando uma requisição que envia uma chave de API inválida 


Vamos criar agora um teste que realiza uma requisição que não 
envia uma chave da API propositalmente inválida. A seguir o código 
do método desse teste. 


def 'deveria receber 403 ao tentar recuperar um IMC informando uma chave 
da API inválida'() { 

when: 

this.cliente.get(path: this.uriEndpoint, cabeçalhos : ['x-api-key' 
'chave-INVALIDA']) 


then: 
HttpResponseException ex = thrown(HttpResponseException) 
ex. statusCode == HttpStatus.SC FORBIDDEN 


} 


No bloco when , usamos O cliente para enviar uma requisição com o 
método cer para a URI /imcs da API. O JSON está perfeito e 
enviamos uma chave de API, porém não uma válida. 


No bloco then apenas verificamos se a resposta chegará com o 
status 403 (Forbidden). 


8.6 Testando o Endpoint GET /imcs 


Para testar o Endpoint GET /imcs/{id} , vamos criar a classe de testes 
ImcApiListaTest , Que é muito parecida com a ImcApiGetUmTest . À 
diferença é que o atributo uriEndpoint possui outro valor. Portanto, o 
início dessa classe fica como no código a seguir. 


package unit.br.com.livrospockframework.capituloos 
// mesmos imports da ImcApiGetUmTest 
class ImcApiGetListaTest extends Specification { 


def uriEndpoint = '/imcs/' 
// demais atributos de instância e métodos criarHeader() e setup() 
idênticos aos da ImcApiGetUmTest 


O atributo uriEndpoint é uma URI que indica que queremos recuperar 
vários cálculos de IMC. 


Testando uma requisição sem erros que solicita todos os 
cálculos de IMC 


Vamos criar um teste na classe ImcapiGetListaTest que faz uma 
requisição sem os parâmetros de filtro ( apartir € ate ) sem erros e 
que verifica se a resposta está conforme o esperado para esse tipo 
de requisição. Vejamos esse teste a seguir: 


def 'deveria recuperar lista de todos os IMCs'() { 


when: 
HttpResponse response = this.cliente.get(path: this.uriEndpoint, 
headers: this.criarHeader()) 


then: 'Validando os cabeçalhos da resposta' 
response.status == HttpStatus.SC OK 


response. getEntity().contentType.value.startsWith(ContentType.JSON.toStrin 
g()); 


and: 'Validando o corpo da resposta' 

response.data.size() > O 

for (item in response.data) { 
item.id instanceof Number 
item.nome instanceof String 
item.imc instanceof Number 
item.condicao instanceof String 


} 


No bloco when , usamos O cliente para enviar uma requisição com o 
método HTTP cer para o Endpoint cer /imcs . O atributo headers 
recebe o mapa criado no método criarHeader() , que contém a chave 
de API válida para a chamada de qualquer Endpoint da API. 
Armazenamos o resultado da requisição no objeto response do tipo 
org.apache.http.HttpResponse . 


Usamos o bloco then para validar somente os cabeçalhos da 
resposta recebida pelo Endpoint. Primeiro validamos se o status que 


chegou foi 220 (ok) . Em seguida, verificamos se O Content-type da 
resposta foi application/json. 


No bloco and verificamos se o JSON do corpo da resposta está 
conforme a documentação. Primeiro testamos se a lista JSON que 
chegou contém mais de um elemento. Em seguida, para cada 
elemento da lista, verificamos se o atributo id existe e é um valor 
numérico. Depois, verificamos se o atributo nome existe e é um valor 
alfanumérico. Em seguida, verificamos se o atributo imc existe e é 
um valor numérico. Por fim, verificamos se o atributo condicao existe 
e é um valor alfanumérico. 


Testando uma requisição sem erros que solicita listas filtradas 
de cálculos de IMC 


Vamos criar um teste na classe ImcapiGetListaTest que faz uma 
requisição com os parâmetros de filtro ( apartir e/ou ate ) sem erros 
e que verifica se a resposta está conforme o esperado para esse 
tipo de requisição. Vejamos esse teste a seguir: 


def 'deveria filtrar corretamente os IMCs'() { 


when: 'Somente parâmetro "apartir" impossível de existir' 
HttpResponse response = this.cliente.get(path: this.uriEndpoint, 
headers: this.criarHeader(), query: [apartir: Integer.MAX VALUE]) 


then: 'Validando os cabeçalhos da resposta' 
response.status == HttpStatus.SC NO CONTENT 


and: 'Validando o corpo da resposta' 
response.data == null 


when: 'Somente parâmetro "ate" impossível de existir' 
response = this.cliente.get(path: this.uriEndpoint, headers: 


this.criarHeader(), query: [ate: Integer.MIN VALUE]) 


then: 'Validando os cabeçalhos da resposta' 
response.status == HttpStatus.SC NO CONTENT 


and: 'Validando o corpo da resposta' 
response.data == null 


when: 'Parâmetros "apartir" e "ate" com valores extremos possíveis' 

response = this.cliente.get(path: this.uriEndpoint, headers: 
this.criarHeader(), query: [apartir: Integer.MIN VALUE, ate: 
Integer.MAX VALUE]) 


then: 'Validando os cabeçalhos da resposta' 
response.status == HttpStatus.SC OK 


response. getEntity().contentType.value.startsWith(ContentType.JSON.toStrin 
g()); 


and: 'Validando o corpo da resposta' 

response.data.size() > O 

for (item in response.data) { 
item.id instanceof Number 
item.nome instanceof String 
item.imc instanceof Number 
item.condicao instanceof String 


} 


Neste teste, temos três cenários de consulta com filtros. Por isso 
três trios de blocos when / then / and . 


No primeiro bloco when , enviamos uma requisição com o parâmetro 
apartir contendo o máximo valor permitido para um número inteiro. 
A ideia é fazer uma chamada sem erros, mas que não retorne 
nenhum JSON na resposta, pois não há como o menor valor de IMC 
calculado ser um número tão alto. 


No primeiro bloco then apenas verificamos se o status que chegou 
foi O 204 (No content). 


No primeiro bloco and apenas verificamos se o corpo da resposta 
está vazio (sem nenhum JSON). 


No segundo bloco when , enviamos uma requisição com o parâmetro 
ate contendo o mínimo valor permitido para um número inteiro. A 
ideia é fazer uma chamada sem erros, mas que não retorne nenhum 
JSON na resposta, pois não há como o maior valor de IMC 
calculado ser um número tão baixo. 


No segundo bloco then apenas verificamos se o status que chegou 
foi O 204 (No content). 


No segundo bloco and apenas verificamos se o corpo da resposta 
está vazio (sem nenhum JSON). 


No terceiro bloco when , enviamos uma requisição com os parâmetros 
apartir € ate contendo os valores mínimo e o máximo permitidos 
para um número inteiro, respectivamente. A ideia é fazer uma 
chamada que acabe trazendo o máximo de registros possível. 


Usamos o terceiro bloco then para validar somente os cabeçalhos da 
resposta recebida pelo Endpoint. Primeiro validamos se o status que 
chegou foi 220 (ok) . Em seguida, verificamos se O Content-type da 
resposta foi application/json. 


No terceiro bloco and verificamos se o JSON do corpo da resposta 
está conforme a documentação. Primeiro testamos se a lista JSON 
que chegou contém mais de um elemento. Em seguida, para cada 
elemento da lista, verificamos se o atributo id existe e é um valor 
numérico. Depois, verificamos se o atributo nome existe e é um valor 
alfanumérico. Em seguida, verificamos se o atributo imc existe e é 
um valor numérico. Por fim, verificamos se o atributo condicao existe 
e é um valor alfanumérico. 


8.7 Testando o Endpoint DELETE /imcs/fid) 


Para testar o Endpoint DELETE /imcs/{id} , vamos criar a classe de 
testes ImcapiDeleteTest , que é muito parecida com a ImcapiGetUmTest . 
Os métodos criarHeader() € setup() podem ser idênticos. A diferença 
é que o atributo uriEndpoint indica o identificador do recurso que será 
se pretende excluir. Portanto, o início dessa classe fica como no 
código a seguir. 


package unit.br.com.livrospockframework.capituloo8s 
// mesmos imports da ImcApiGeteUmTest 
class ImcApiDeleteTest extends Specification ( 


def uriEndpoint = '/imcs/1' 
// demais atributos de instância e métodos criarHeader() e setup() 
idênticos aos da ImcApiGetUmTest 


O atributo uriEndpoint é uma URI que indica que queremos excluir o 
cálculo de IMC de identificador 1 . 


Testando uma requisição sem erros 


Vamos criar um teste na classe ImcapiDeleteTest que faz uma 
requisição sem erros e que verifica se a resposta está conforme o 
esperado para esse tipo de requisição. Vejamos esse teste a seguir: 


def 'deveria excluir um registro de IMC'() { 

when: 

HttpResponse response = this.cliente.delete(path: this.uriEndpoint, 
headers: this.criarHeader()) 


then: 'Validando os cabeçalhos da resposta" 
response.status == HttpStatus.SC OK 
} 


No bloco when , usamos O cliente para enviar uma requisição com o 
método HTTP veLETE para o Endpoint DELETE /imcs/fid) . O atributo 
headers recebe o mapa criado no método criarHeader() , que contém a 
chave de API válida para a chamada de qualquer Endpoint da API. 


Usamos o bloco then para validar se o status que chegou foi 280 (ok) 
Testando uma requisição informando identificador inválido 


Vamos criar agora um teste que realiza uma requisição com 
identificador propositalmente inexistente para o Endpoint DELETE 
/imcs/(id) para verificar se a resposta está conforme a 
documentação. A seguir o código do método desse teste. 


def 'deveria receber 404 ao tentar excluir IMC com identificador 
inexistente" (O { 

when: 

this.cliente.delete(path: '/imcs/-19', headers: this.criarHeader()) 


then: 
HttpResponseException ex = thrown(HttpResponseException) 
ex. statusCode == HttpStatus.SC NOT FOUND 


} 


No bloco when , usamos O cliente para enviar uma requisição com o 
método DELETE para o Endpoint DELETE /imcs/{id} . Como identificador 
usamos um número negativo e números negativos não costumam 
ser usados como identificadores de recursos em APIs. Com isso 
esperamos que a resposta seja de status 404, conforme 
especificado. 


Usamos o bloco then apenas para verificar se a resposta chegará 
com o status 404 (Not found). 


Conclusão 


Neste capítulo vimos como criar testes funcionais para RESTful 
APIs com Spock. No próximo capítulo, veremos algumas 
funcionalidades avançadas do framework, que ajudam a resolver 
vários pequenos problemas no cotidiano da execução de testes 
automatizados. 


CAPÍTULO 9 
Recursos avançados 


Com o conteúdo que já estudamos até aqui já é possível criar 
qualquer tipo de teste dentre os quais o Spock se propõe a 
implementar. Porém, para situações pontuais que poderiam exigir 
workarounds e/ou repetição de código, este capítulo apresenta 
alguns recursos avançados do Spock. 


9.1 Ignorando testes 


Pode ser que você precise que alguns dos testes automatizados 
que criou sejam ignorados. Mas, por que eu criaria um teste para 
ignorá-lo? Existem várias situações que exigem isso, dentre as 
quais destacam-se: 


e Uma funcionalidade que estava funcional e testada ficou 
desabilitada por um tempo mas voltará a funcionar. Enquanto 
isso, ignoramos seu teste; 


e Foi adotada a técnica TDD (falaremos um pouco dela logo 
mais), o que exige que o teste seja criado antes da 
funcionalidade. Portanto, seu teste deve ser ignorado se falhar; 


e Uma funcionalidade só foi projetada para funcionar em 
determinadas condições de ambiente (sistema operacional, 
propriedades de sistema etc.). Logo, seus testes devem ser 
ignorados quando executados fora dessas condições. 


Caso seja necessário simplesmente ignorar a execução de 
determinados testes, poderíamos simplesmente comentar ou 
mesmo excluir o código do teste. Mas essas são medidas pouco 
profissionais. O Spock possui anotações que permitem manter o 


código do teste na classe, porém ignorando sua execução total ou 
parcialmente. 


Ignorando testes com «ignore 


A anotação @spock. lang. Ignore é usada para que o Spock ignore a 
execução de um método ou de toda uma classe de testes. Essa 
anotação aceita, opcionalmente, um valor string para que seja 

descrito o motivo por que a classe ou teste está sendo ignorado. 


Quando usada sobre a definição da classe, ela faz com que 
todos os seus métodos de teste sejam ignorados. A classe 
simplesmente é ignorada na fase de testes do Maven. Por exemplo, 
vamos supor que precisemos ignorar todos os testes da classe 
unit.br.com.livrospockframework. capituloo8. ImcApiPostTest do capítulo 
anterior. Basta usar a @Ignore como no código a seguir. 


package unit.br.com.livrospockframework.capituloos 
import spock.lang. Ignore 


MIgnore 
class ImcApiPostTest extends Specification { 


} 


Caso quisermos indicar o motivo de estarmos ignorando a classe, 
basta por um valor string na anotação @Ignore , como no próximo 
exemplo. 


@Ignore('O Endpoint POST /imcs/calculo está desabilitado até 2019') 
class ImcApiPostTest extends Specification { 


Quando usada sobre a assinatura de um método, ela faz com 
que o método anotado seja ignorado quando a classe de teste for 
executada. O método não é executado na fase de testes do Maven. 
Por exemplo, vamos supor que precisemos ignorar um dos testes da 
classe unit.br.com.livrospockframework.capituloo8. ImcApiPostTest do 


capítulo anterior. Basta usar a @Ignore sobre o método desejado, 
como no código a seguir. 


class ImcApiPostTest extends Specification { 


(Ignore 
def "deveria receber 401 ao tentar calcular IMC sem informar a chave 
da API'() { 


} 


Com a configuração feita no último código, o método 'deveria receber 
401 ao tentar calcular IMC sem informar a chave da API'() não será 
executado na fase de testes do Maven. 


E, assim como quando usamos essa anotação sobre a classe, sobre 
um método também podemos indicar o motivo de o teste estar 
sendo ignorado, como no próximo código. 


class ImcApiPostTest extends Specification { 


@Ignore('Aparentemente a API não devolve mais 401, só 403') 
def 'deveria receber 401 ao tentar calcular IMC sem informar a chave 
da API'() { 


} 
ignorando testes com @IgnoreRest 


Imagine que uma classe de testes precise que todos os métodos, 
menos um, sejam ignorados. Isso pode ocorrer, por exemplo, 
quando um conjunto de funcionalidades é refatorada, deixando-as 
suspensas por um tempo. Nesse caso, em vez de usar a @Ignore 
sobre todos os métodos menos um, podemos simplesmente anotar 
apenas um método com @spock.lang.IgnoreRest . Essa anotação não 
possui nenhum atributo. 


No código de exemplo a seguir, solicitamos ao Spock que ignore 
todos os testes da classe 
unit.br.com.livrospockframework.capituloo8. ImcApiGetUmTest do capítulo 
anterior, menos o 'deveria recuperar um IMC'(). 


package unit.br.com.livrospockframework.capituloos 
import (spock. lang. IgnoreRest 
class ImcApiGetUmTest extends Specification { 


(MIgnoreRest 
def "deveria recuperar um IMC'() 1 


// demais métodos de teste 


} 


Com a configuração feita no último código, quando o Maven testar a 
classe ImcApiGetUmTest , apenas o método 'deveria recuperar um IMC'() 
será executado, não importa quantos métodos mais de teste 
existam na classe. 


É possível usar a @Ignorerest em mais de um método? 


Sim, é possível. Supondo que uma classe de testes tenha 10 (dez) 
métodos e usemos a @IgnoreRest sobre 2 (dois) deles, estes serão os 
únicos a serem executados. 


Ignorando resultado de testes com @Pendingf eature 


A anotação Mpock.lang.PendingFeature SÓ pode ser usada em métodos 
e indica que o teste será executado, porém que deve falhar. Ou 
seja, caso um teste anotado com ela passe, o Spock vai se esperar 
que o teste falhe para marcá-lo como passed . 


Atenção! Essa anotação não ignora o teste. Ele sempre será 
executado se anotado com ela! 


Como o nome sugere, essa anotação deve estar presente em testes 
de funcionalidades que ainda não estão prontas, por isso esse 
comportamento de esperar que o teste falhe. Quando se trabalha 
com a metodologia TDD é comum a criação de testes antes da 
própria funcionalidade. 


O quE É TDD 


É uma técnica proposta por Kent Beck em 2003 em seu clássico 
livro Test-Driven Development: By Example. Nela, o ciclo de 
desenvolvimento deve ser: 


1. Crie um teste antes da funcionalidade. 


2. Execute o teste. Ele vai, lógico, falhar no início (lembre-se de 
que a funcionalidade ainda não foi criada). Aí então é que você... 


3. Escreve o código da funcionalidade. 


4. Execute os testes automatizados e veja se executarem com 
Sucesso. 


5. Refatore o código. 


Kent defende que essa técnica reduz consideravelmente a 
execução de debugs e força o desenvolvedor a conhecer 
precocemente e profundamente o código que vai criar ou evoluir. 





Para exemplificar, vamos supor que um dos testes da classe 
unit.br.com.livrospockframework. capituloo8. ImcApiDeleteTest do capítulo 
anterior precise necessariamente falhar por ainda se tratar de um 
teste de uma funcionalidade que não deveria estar funcionando. 


package unit.br.com.livrospockframework.capituloos 
import (spock.lang.PendingFeature 


class ImcApiDeleteTest extends Specification ( 


(OPendingFeature 
def "deveria excluir um registro de IMC'() { 
// verificação que faz o teste NÃO passar 


// demais métodos de teste 


} 


No último código, o teste é executado e, caso o teste falhe, o Spock 
fará com que o Maven veja o teste como passed . Porém, caso o teste 
passe, aí sim o Maven vai se comportar como teste que falhou. 
Nesse caso o log de erro seria como o do exemplo a seguir. 


Failed tests: 
deveria excluir um registro de IMC Feature is marked with 
@PendingFeature but passes unexpectedly 


A ideia dessa anotação é deixar o teste pronto para o caso de 
funcionalidade não concluída. Assim, quando a funcionalidade ficar 
pronta, basta tirar a anotação @PengingFeature . 


Não era melhor simplesmente por uma @Ignore sobre o teste? A 
@Ignore Simplesmente ignora a execução do teste. A @PengingFeature É 
para quando queremos realmente ter certeza de que a 
funcionalidade ainda não existe. E só é possível ter essa certeza 
testando-a. 


Ignorando testes com «rgnorerf 


Vimos como ignorar testes, mas, e se para ignorar um teste 
precisarmos de uma condição? Um exemplo disso seria verificar se 
o código testado está sendo testado em um ambiente homologado, 
ou seja, se determinadas configurações do ambiente estão 
adequadas ao sistema. É possível que determinada funcionalidade 
de um sistema não seja compatível com o sistema operacional da 
família Windows ou com o Java 7 ou com determinado kernel do 
Linux. Para situações como essa, existe a anotação 
(Ospock. lang. IgnoreIf. 


A anotação pIgnorerf pode ser usada sobre a classe ou sobre um 
método de teste. Ela sempre espera uma closure cujo conteúdo 
será usado para avaliar se o teste deve ou não ser ignorado. Seu 
uso seria como no código de exemplo a seguir. 


import spock.lang. IgnoreIf 
class AlgumaClasseTest extends Specification { 


(MIgnoreIf((os.windows)) 
def 'cenário não executado em Linux'() { 


} 


Na anotação @Ignorerf do último código, configuramos que o método 
de teste anotado será ignorado caso o sistema operacional (SO) 
seja da família Windows. Mas, o que é esse os ? 


No Spock, existem algumas classes utilitárias que facilitam a 
recuperação de várias informações do ambiente onde os testes 
estão sendo executados. São elas: 


e spock.util.environment.OperatingSystem : Classe que possui 
métodos que retornam informações sobre o sistema 
operacional (SO) onde o teste está sendo executado. 


e spock.util.environment.Jvm : Classe que possui métodos que 
retornam informações sobre a JVM onde o teste está sendo 
executado. 


Para facilitar o uso dessas classes utilitárias operatingsystem € Jvm , 
existem atalhos, descritos a seguir. 


os - Atalho para spock.util.environment.OperatingSystem 


e os.name : NOME completo 
e os.version | Versão 


e os.family : família (Windows, Linux, MacOs, Solaris ou Other) 

e os.windows : Verdadeiro se o SO for da família Windows 

e os.linux : Verdadeiro se o SO for da família Linux 

e os.macos : Verdadeiro se o SO for da família MacOs 

e os.solaris : Verdadeiro se o SO for da família Solaris 

e os.other : verdadeiro se o SO não for de nenhuma das famílias 
anteriores 


Exemplos de uso: 


Teste que deve ser ignorado se o SO for um Linux: 


MIgnoreIf((os.linux)) 
def 'cenário não executado em Linux'() { 


} 
Teste que deve ser ignorado se o SO for um Linux ou Solaris: 


@IgnoreIf({os.linux || os.solaris}) 
def 'cenário não executado em Linux nem Solaris'() { 


} 


Teste que deve ser ignorado se a versão do SO for a 4.13.0-32- 
generic: 


@IgnoreIf({os.version == '4.13.0-32-generic' }) 
def 'cenário não executado em SO de versão 4.13.0-32-generic'() { 


} 
jvm - Atalho para spock.util.environment.Jvm 


e jvm.javaSpecificationVersion : retorna a versão de especificação 
da JVM (1.6, 1.7, 1.8 etc.) 

e jvm.javaVersion : retorna a versão da JVM (1.8.0_151) 

e jvm.java5 : Verdadeiro de a JVM for da família Java 5 

e jvm.java5Compatible : verdadeiro de a JVM for compatível com 
Java 5 


e jvm.java6 : Verdadeiro de a JVM for da família Java 6 

e jvm.java6Compatible : Verdadeiro de a JVM for compatível com 
Java 6 

e jvm.javaz : Verdadeiro de a JVM for da família Java 7 

e jvm.java7Compatible : Verdadeiro de a JVM for compatível com 
Java 7 

e jvm.javas : Verdadeiro de a JVM for da família Java 8 

e jvm.java8Compatible : verdadeiro de a JVM for compatível com 
Java 8 

e jvm.javao : Verdadeiro de a JVM for da família Java 9 

e jvm.java9Compatible : Verdadeiro de a JVM for compatível com 
Java 9 


Exemplo de uso: teste que deve ser ignorado se a JVM da execução 
não for compatível com Java 7: 


MIgnoreIf((!jvm.java7Compatible)) 
def 'cenário ignorado em JVM não compatível com Java 7'() { 


} 


Caso você queira sujeitar a execução ou não de um teste a 
propriedades do sistema ou informações de ambiente, é possível 
usar os atalhos a seguir. 


sys - atalho para System.getProperty(?) Exemplo de uso: teste que 
deve ser ignorado caso o país do usuário seja os Estados Unidos 
(US): 


@IgnoreIf({sys['user.country']=='US'}) 
def 'cenário não executado caso o país do usuário seja US'() { 


} 


env - atalho para system.getenv(?) Exemplo de uso: teste que deve ser 
ignorado caso o SHELL do SO for /bin/bash : 


MIgnoreIf((env['SHELL']=='/bin/bash'3) 
def 'cenário não executado se a SHELL do SO for /bin/bash'() { 


Indicando quando um teste deve ser executado com requires 


A anotação àspock. lang.Requires funciona de forma muito parecida 
com a spock. lang. IgnoreIf . A diferença é que a condição que se 
coloca na anotação indica o motivo de o teste ser executado, e não 
ignorado. Por exemplo, vamos supor que precisemos que um teste 
deva ser executado somente se o SO for um Linux: 


QRequires((os.linux)) 
def 'cenário que executa somente em Linux'() { 


9.2 Tolerância de tempo de um teste com 
(DTimeout 


Algumas funcionalidades têm como requisito funcional um limite de 
tempo para execução. Um exemplo disso seria o tempo que um 
caixa eletrônico deve esperar até que consiga expelir o dinheiro 
solicitado em um saque. Com o Spock é possível fazer com que um 
teste falhe automaticamente caso leve mais que um determinado 
tempo para concluir sua execução, por meio do uso da anotação 
(Ospock. lang.Timeout . 


Essa anotação pode estar sobre a classe, o que indica um tempo de 
tolerância de execução para todos os seus testes. Ela também pode 
estar sobre a assinatura de apenas um método, o que indica a 
tolerância de tempo apenas de seu teste. 


No código de exemplo a seguir, vamos supor que precisemos que 
os testes da classe 
unit.br.com.livrospockframework. capituloo8. ImcApiPostTest do capítulo 


anterior levem, cada um, no máximo 3 segundos para concluir sua 
execução. Basta usar a Timeout Sobre a classe, como no código a 
seguir. 


package unit.br.com.livrospockframework.capituloo8s 
import spock.lang.Timeout 


@Timeout(3) 
class ImcApiPostTest extends Specification { 


} 


O valor inteiro usado na anotação @Timeout é O tempo em segundos 
que cada um de seus métodos deve levar para ser executado sem 
ser marcado como teste com falha. 


Caso precisemos determinar o tempo limite da execução de apenas 
um método de teste, podemos usar essa anotação sobre um teste, 
como no código de exemplo a seguir. 


class ImcApiPostTest extends Specification { 


(OTimeout (4) 
def "deveria calcular e registrar IMC'() { 


} 


No último exemplo, o teste do método 'deveria calcular e registrar 
IMC' () tem um tempo de tolerância de 4 segundos para execução. 


Como é a indicação do erro em caso de tempo excedido? 


Caso o tempo configurado na classe ou no método tenha sido 
excedido durante a execução do método, o log de erro será como 
no exemplo a seguir. 


<<< FAILURE! - in 
unit.br.com.livrospockframework.capituloo8. ImcApiPostTest 


deveria calcular e registrar 
IMC(unit.br.com.livrospockframework.capituloo8. ImcApiPostTest) Time 
elapsed: 4.002 sec <<< FAILURE! 
org.spockframework.runtime.SpockTimeoutError: Method timed out after 4,00 
seconds 


at 
unit.br.com.livrospockframework.capituloo8. ImcApiPostTest.deveria calcular 
e registrar IMC(ImcApiPostTest.groovy:13) 


E se eu quiser indicar milissegundos, minutos, horas ou outra 
unidade de tempo? Divido e multiplico? 


Não. A anotação @Timeout permite indicar a unidade de tempo para 
facilitar a leitura do código do teste e evitar gastar tempo em 
cálculos de conversão de tempo. Basta usar o atributo value de 
forma explícita e o atributo unit , que espera um valor do tipo enum 


java.util.concurrent.TimeUnit. 


Por exemplo, vamos reconfigurar o último teste para que tenha uma 
tolerância de tempo de 2 minutos. 


class ImcApiPostTest extends Specification { 


(OTimeout (value=2, unit=TimeUnit.MINUTES) 
def "deveria calcular e registrar IMC'() { 


} 
Os valores disponíveis na enum Timeunit são: 


e NANOSECONDS (Nanossegundos) 
e MICROSECONDS (Microssegundos) 
e MILLISECONDS (Milissegundos) 

e SECONDS (Segundos) 

e MINUTES (Minutos) 

e HOURS (Horas) 

e DAYS (Dias) 


9.3 Executando os testes na ordem em que estão 
na classe com (DStepwise 


Em certos tipos de teste, principalmente em testes funcionais, a 
sequência dos testes é muito relevante. Lembra dos testes que 
criamos no capítulo 8, no qual testamos uma RESTful API? Imagine 
que quiséssemos criar uma sequência de testes em que criaríamos 
um registro de IMC, verificaríamos se ele realmente fora criado, o 
excluiríamos e verificaríamos se ele realmente fora excluído. Uma 
alternativa seria criar um único teste, mas ele seria um método 
muito grande e de baixa coesão, não concorda”? E se pudéssemos 
realizar essa sequência sendo que cada passo estaria em seu 
próprio método teste” Com o Spock isso é possível pelo simples 
uso da anotação (Ospock. lang.Stepwise. 


A anotação astepwise só pode ser usada sobre a definição da 
classe. Quando está presente, os métodos de teste da classe são 
executados na ordem em que estão no arquivo. 


Para exemplificar seu uso, vamos criar uma nova classe de testes, a 
unit.br.com.livrospockframework. capituloo9. IMCSequenciaCRUDTest , Na qual 
criaremos os seguintes testes: 


e Calcular e registrar IMC; 

e Recuperar o IMC recém-criado; 

e Excluir registro de IMC recém-criado; 

e Tentar recuperar o IMC recém-excluído e não o encontrar. 


Note que a ordem correta de execução desses testes é imperativa 
para que a classe de teste passe. Já pensou se testarmos a 
exclusão de um registro que ainda nem existe? Segue o código na 
nova classe de teste. 


package unit.br.com.livrospockframework.capituloo9 


import spock.lang.Stepwise 


QStepwise 
class IMCSequenciaCRUDTest extends Specification { 


def 'calcular e registrar IMC'() { ... } 
def 'recuperar o IMC recém criado'() { ... } 
def "excluir registro de IMC recém criado'() { ... } 


def 'tentar recuperar o IMC recém excluído e não encontrá-lo'() { ... 


} 
} 


No código anterior, a exata ordem na qual estão os métodos será a 
ordem de sua execução devido à presença da anotação @Stepwise 
sobre a classe. 


E se houver métodos com «ignore, @IgnoreIf OU GRequires ? A 
combinação da @Stepwise com as que podem fazer com que testes 
sejam ignorados não influencia na ordem. Os métodos que tiverem 
que ser ignorados o serão. Os demais continuam sendo executados 
na ordem em que estão na classe. 


9.4 Compartilhando objetos entre testes com 
@Shared 


Em certos tipos de testes, como nos em testes funcionais, a saída 
de uma etapa pode servir como entrada para a seguinte. Exemplos 
desse tipo de situação: 


e Teste de autenticação como este: 

e Realize uma autenticação; 

e Verifique se o usuário da sessão é o que se autenticou 
anteriormente. 


e Teste em uma REST API como este: 


e Crie um recurso; 

e Guarde o identificador que o novo recurso ganhou; 

e Exclua o recurso recém-criado a partir do identificador recém- 
obtido. 


Para situações como essas, o Spock possui a anotação 

Qspock. lang.Shared , que só pode ser usada na definição de 
atributos de instância. Ela permite que um atributo anotado com 
ela seja compartilhado entre os diversos métodos de teste. 


Quando um atributo em uma classe de testes Spock é anotado com 
Shared , seu valor é mantido entre os diversos métodos de teste, a 
não ser que um método o altere. Nesse caso continua o mesmo até 
que o um próximo método venha a alterá-lo. Esse comportamento 
está ilustrado na figura a seguir. 


testel() testeZ() teste3() teste4() teste5() 


atributoCompartilhado 


anotado com EShared valor atribuído valor atribuído valor atribuído 


em testel() em teste3() em teste4() 


Figura 9.1: Ciclo de vida de um atributo anotado com @ Shared. 


Tomando como exemplo a classe de teste ImcsequenciacRuDTest dO 
tópico anterior, poderíamos definir um atributo compartilhado entre 
os testes, como o código-fonte a seguir. 


// pacote e imports 


QStepwise 
class IMCSequenciaCRUDTest extends Specification { 


(Shared 
def idRecursoCriado 


def 'calcular e registrar IMC'() { 
// blocos do teste 


idRecursoCriado = resposta.id 


def 'recuperar o IMC recém criado'() { 
// blocos do teste usando o idRecursoCriado 


def "excluir registro de IMC recém criado'() { 
// blocos do teste usando o idRecursoCriado 


} 


Nesse último código de exemplo, o atributo idRecursoCriado foi 
alterado no teste 'calcular e registrar IMC'(). Como a classe de 
testes está anotada com @Stepwise , os métodos serão executados na 
sequência em que estão no arquivo, portanto, o valor de 
idRecursoCriado Será atribuído no primeiro método e permanecerá o 
mesmo para os demais. 


9.5 Restaurando propriedades do sistema com 
@RestoreSystemProperties 


Alguns cenários de teste exigem que sejam configuradas algumas 
propriedades de sistema. Porém, para evitar efeitos colaterais em 
outros testes do mesmo projeto, é mais seguro reverter quaisquer 
alterações nessas propriedades após a execução dos testes. Para 
essa tarefa, podemos usar a anotação 
@spock.util.environment.RestoreSystemProperties sobre a classe de teste. 


Por exemplo, vamos supor que tivemos que alterar uma propriedade 
na classe unit.br.com.livrospockframework.capituloo8. ImcApiPostTest do 
capítulo anterior, mas queremos que essa alteração seja revertida 
após todos os testes dessa classe. Basta fazer como no código a 
seguir. 


MRestoreSystemProperties 
class ImcApiPostTest extends Specification { 


def "deveria calcular e registrar IMC'() { 
given: 
System.setProperty("api-token", "a5e61b00-db1f-406b") 


// demais testes da classe 


Após a execução de todos os testes da classe do último código, a 
propriedade de sistema api-token será excluída caso tenha sido 
criada no teste ou voltará para seu valor anterior caso já existisse 
antes da execução dos testes dessa classe. 


9.6 Indicando referências 


Em certos projetos é pertinente indicar referências teóricas para os 
cenários dos testes e/ou indicar que issue motivou a criação do 
teste. Por exemplo, em projetos com cálculos de impostos (onde 
seriam indicadas as leis) e projetos de integrações de sistemas 
(onde seriam indicadas as origens dos sistemas externos). Para 
esses tipos de referências há anotações do Spock que as deixam 
mais explícitas e claras. 


Indicando referências com @see 


Imagine que determinado teste foi criado para garantir que uma 
funcionalidade siga uma norma do governo, uma verdade científica 
comprovada ou uma regra específica do cliente segundo algum 
documento oficial dele disponível na internet. Você pode 
simplesmente criar um javadoc para a classe e/ou métodos de teste. 
Ou, se quiser um recurso mais assertivo e simples de ler, pode usar 
a anotação @spock.lang.See do Spock. 


A anotação @see espera como valor uma ou várias URLs, indicando a 
fonte online que contém o embasamento ou a justificativa do teste. 
Essa anotação pode estar tanto na definição da classe quanto na 
dos métodos de teste. 


Como exemplo, vamos supor que quiséssemos deixar claro onde no 
baseamos para montar o cenário de testes da calculadora de IMC 
do capítulo 5. Poderíamos fazer a seguinte alteração na classe 


unit.br.com.livrospockframework.capituloo5.FaixaImcTest . 


package unit.br.com.livrospockframework.capituloos 
import spock.lang.See 
class FaixaImcTest extends Specification ( 


QSee("http://bvsms.saude.gov.br/bvs/dicas/215 obesidade.html') 
def 'IMC deve estar na faixa correta'() { 


} 


Veja que fica muito claro que temos uma referência do tipo "veja 
mais em" sobre o método 'īmc deve estar na faixa correta'(). Se 
fosse necessário usar mais de uma referência, sem problemas, 
basta fazer como no próximo código e usar um vetor de URLs na 
See . 


class FaixaImcTest extends Specification ( 
QSee(["http://bvsms.saude.gov.br/bvs/dicas/215 obesidade.html", 


“http://intranet.sesporte.ce.gov.br/imc/']) 
def 'IMC deve estar na faixa correta'() { 


> 
Indicando referências com @Issue 


Imagine que determinado teste foi criado para cumprir algo que foi 
solicitado e está registrado em uma issue do GitHub, BitBicker, Jira, 


ou afins. Se quiser um recurso mais assertivo e simples de ler que o 
javadoc , pode usar a anotação gspock. lang. Issue do Spock. 


A anotação @Issue espera como valor uma ou várias URLs, indicando 
o endereço da issue. Essa anotação pode estar tanto na definição 
da classe quanto na dos métodos de teste. 


Como exemplo, vamos supor que quiséssemos deixar claro em qual 
issue nos baseamos para montar o cenário de testes da calculadora 
de IMC do capítulo 5. Poderíamos fazer a seguinte alteração na 


classe unit.br.com. livrospockframework.capitulo05.FaixaImcTest . 


import spock.lang. Issue 
class FaixaImcTest extends Specification { 


(MIssue("https://github.com/perfil/repositorio/issues/12') 
def 'IMC deve estar na faixa correta'() { 


} 


Veja que fica muito claro que temos uma referência do tipo "detalhes 
sobre esse teste na issue" sobre o método 'IMC deve estar na faixa 
correta'() . Se fosse necessário referenciar mais de uma issue, 
bastaria fazer como no próximo código e usar um vetor de URLs na 


@Issue . 
class FaixaImcTest extends Specification { 
MIssue(["https://github.com/perfil/repositorio/issues/12', 
“https://github.com/perfil/repositorio/issues/144']) 
def 'IMC deve estar na faixa correta'() { 
} 


Conclusão 


Neste capítulo, vimos recursos avançados do Spock framework que 
propõem soluções prontas simples para pequenas necessidades 


que possam surgir em nossos códigos de testes, que vão desde a 
capacidade de ignorar testes, definir um limite de tempo para 
execução até a documentar melhor os testes no próprio código. No 
próximo capítulo, veremos como testar metaprogramação com 
Spock. 


CAPÍTULO 10 
Testando metaprogramação (anotações) 


Já estudamos até aqui a imensa maioria dos testes possíveis de 
serem criados com Spock e, várias vezes, lembramos da 
importância dos testes automatizados. Porém, há um certo tipo de 
detalhe que programamos e costuma ser negligenciado nos testes: 
a metaprogramação. Neste capítulo, veremos como testar a 
metaprogramação em projetos Java, ou seja, anotações. 


10.1 Metaprogramação em Java: anotações 


Na plataforma Java, metaprogramação pode ser feita por meio de 
annotations (comumente traduzido como anotações). Esse recurso 
foi introduzido na versão 5 da linguagem Java (lançada em 2004). 
Desde então, passou a ser cada vez mais usado tanto pelas mais 
diversas especificações oficiais da plataforma (por exemplo: JPA , 
Servlets API ) quanto pelos inúmeros frameworks e bibliotecas 
compatíveis com a JVM (como soluções spring e ason ). 


METAPROGRAMAÇÃO 


Segundo o livro Generative Programming: Methods, Tools, and 
Applications, escrito por Krzysztof Czarnecki e Ulrich Eisenecker, 
metaprogramação é a técnica de programação na qual algumas 
partes de um programa funcionam como configurações. 
Exemplos disso são pré-processadores e compiladores, ou 
quando um programa manipula outro como se fosse um 
repositório de dados. 


No livro da Caso do Código Componentes reutilizáveis em Java 
com Reflexão e Anotações, escrito por Eduardo Guerra, 
metaprogramação é descrita como um código que trabalha com 
o próprio código. Com ela, um programa pode realizar ações 
computacionais a respeito dele mesmo. 





Em Java, anotações podem estar presentes em diferentes partes do 
código, tais como: 


e Na definição da classe. Nesse caso, definimos uma 
metaprogramação que influenciará toda a classe. Neste livro, 
há exemplos de uso desse tipo de anotação nos capítulo 7 ( 
@Entity ) e capítulo 9 ( @RestoreSystemProperties , @Stepwise O 
outras). 


e Na definição de um atributo. Aqui, definimos uma 
metaprogramação que influenciará somente o atributo anotado. 
Neste livro, há exemplos de uso desse tipo de anotação no 
capítulo 7 ( @Column ). 


e Na definição de um método. Nesse caso, definimos uma 
metaprogramação que influenciará somente o método anotado. 
Neste livro, há exemplos de uso desse tipo de anotação nos 
capítulo 5 ( @unro11 ) e capítulo 9 ( @Ignore , @Timeout e outras). 


10.2 Por que testar anotações? 


As consequências de retirar ou alterar os atributos de uma anotação 
muitas vezes passam despercebidas nos testes unitários e de 
integração. Isso porque as configurações de algumas anotações só 
são solicitadas durante a execução de funcionalidades pontuais de 
um programa. Um exemplo disso são algumas anotações da 
especificação PA : apesar de existir uma configuração que solicita 
ao provedor Jpa que valide o banco de dados conforme o 
mapeamento do projeto, ainda podem ocorrer problemas em tempo 
de execução devido a alterações em anotações. 


Um exemplo concreto seria caso invertamos acidentalmente o 
atributo nullable de uma anotação @column . A etapa de validação do 
JPA não vai notar essa diferença, tampouco vai alterar a definição 
do campo na tabela do banco. Então, caso não exista algum teste 
que simule a criação ou alteração de registro da tabela que possui 
um campo que sofreu essa mudança, o sistema vai lançar uma 
exceção durante uma dessas operações. 


Nesse caso, poderíamos criar um cenário de teste para lidar com a 
obrigatoriedade do campo em questão. Só que não seria um teste 
simples, pois anotações não costumam ser lidas por mecanismos 
simples. Para se ter uma ideia, seria necessário um teste de 
integração que envolvesse várias classes, configurações e mocks 
só para testar cenários para um campo obrigatório de uma entidade 
JPA. 


Para situações assim, já que usamos anotações para facilitar 
configurações por meio de metaprogramação, fica mais fácil 
também usar metaprogramação para testar essas configurações. A 
seguir, vamos usar uma entidade Jpa para demonstrar como realizar 
esse tipo de teste com Spock. 


Além da especificação spa, há inúmeras tecnologias para a 
plataforma Java nas quais anotações são muito usadas e podem ser 
mais bem cobertas por testes. Alguns exemplos: 


e Spring / Spring Boot 

e Especificação JEE (CDI, EJB, JAX-RS etc.) 
Jackson 

e Gson 


10.3 Testando anotações de uma entidade JPA 


Conforme dito há pouco, há várias tecnologias para Java que usam 
bastante do recurso de anotações. Consequentemente, torna-se 
prudente uma maior cobertura dessas metaprogramações. Neste 
capítulo vamos usar como estudo de caso os testes de anotações 
da JPa . Vamos supor que temos uma entidade que está 
corretamente mapeada para sua tabela no banco de dados. É a 
entidade Lutador , mapeada para a tabela lutador , cujo código é: 


package br.com.livrospockframework.capitulo11.entity; 


import javax.persistence.*; 


MEntity 
public class Lutador { 


@Id 
@GeneratedValue(strategy=GenerationType.IDENTITY) 
@Column(name="id_lutador") 

private Long id; 


@Column(nullable = false, length=30) 
private String nome; 


@Column(scale=2) 
private double peso; 


private Calendar nascimento; 


// getters e setters 


Queremos garantir que ela permaneça corretamente mapeada, 
então criamos um teste unitário para testar suas anotações spa. E a 
classe LutadorTest , CUJO início é como o do código a seguir. 


package unit.br.com.livrospockframework.capitulo1ll1; 


import java.lang.reflect.Field 
import javax.persistence.* 
import br.com.livrospockframework.capitulo11.entity.Lutador 


class LutadorTest extends Specification { 
Class classe = Lutador.class; 


// testes 
} 


Definimos o atributo classe apenas para simplificar o código nos 
testes da classe. A seguir, os cenários de testes de 
metaprogramação para cada uma das anotações spa da classe. 


Testando a anotação da classe 


Para testar a metaprogramação da classe, criamos o teste a seguir. 


class LutadorTest extends Specification ( 


def 'classe deve estar anotada com (Entity vazia e sem @Table'() { 
expect: 
Iclasse.getAnnotation(Entity).name() 
Iclasse.getAnnotation(Table) 


// outros testes 


No último teste apenas criamos um bloco expect para testar primeiro 
se existe a anotação @Entity na classe e se seu atributo name é vazio 
ou nulo. Caso a anotação cEntity não esteja presente, ocorrerá uma 
NullPointerException ao tentar invocar O name() e o teste falhará 

corretamente. Em seguida, testamos se a classe não está anotada 


com @Table . Essa é uma anotação comum em projetos 3PA mas, 
como não foi usada, espera-se que não esteja presente na entidade 
Lutador . O fato de ela passar a existir pode gerar problemas em 
tempo de execução, como a busca por uma tabela que não existe, 
por exemplo. 


Caso o teste falhe pela ausência na anotação @Entity , O log de erro 
será como do exemplo a seguir. 


Failed tests: 
LutadorTest.classe deve estar anotada com (QEntity vazia e sem @Table:21 
Condition failed with Exception: 


Iclasse.getAnnotation(Entity).name() 


| null java.lang.NullPointerException: Cannot invoke 
method name() on null object 
class br.com.livrospockframework.capitulo10.entity.Lutador 


Caso o teste falhe pela presença do atributo name na anotação @Entity 
, O log de erro será como do exemplo a seguir. 


Failed tests: 
LutadorTest.classe deve estar anotada com @Entity vazia e sem @Table:21 
Condition not satisfied: 


Iclasse.getAnnotation(Entity).name() 


[| | | 

[| | ehlaiah 

[| Qjavax.persistence. Entity (name=ehlaiah) 

| class br.com.livrospockframework.capitulo10.entity.Lutador 
false 


Caso o teste falhe pela presença da anotação @Table , o log de erro 
será como do exemplo a seguir. 


Failed tests: 
LutadorTest.classe deve estar anotada com (QEntity vazia e sem @Table:22 
Condition not satisfied: 


Iclasse.getAnnotation(Table) 


| 
| 
indexes=[], catalog=) 

| class br.com.livrospockframework.capitulo10.entity.Lutador 


(Djavax.persistence.Table(schema=, name=, uniqueConstraints=[], 


false 
Testando as anotações do atributo id 


Para testar a metaprogramação do atributo id , criamos o teste a 
seguir. 


class LutadorTest extends Specification { 


def '"id" deve estar anotado com (Id, (QGGeneratedValue 
strategy=IDENTITY e (Column name="id lutador" '() { 
setup: 
def campo = classe.getDeclaredField('id') 
def anotacaoId = campo.getDeclaredAnnotation(Id) 
def anotacaoGeneratedValue = 
campo. getDeclaredAnnotation(GeneratedValue) 
def anotacaoColumn = campo.getDeclaredAnnotation(Column) 


expect: 

anotacaoId 

anotacaoGeneratedValue.strategy() == GenerationType. IDENTITY 
anotacaoColumn.name() == "id lutador' 


// outros testes 


No último teste, criamos um bloco setup para recuperar as anotações 
que queremos verificar junto ao atributo id ( @Id , GGeneratedvalue € 
acolum ). No bloco expect , Verificamos primeiro se foi encontrada a 
@Id . Depois, testamos se a @Generatedvalue foi encontrada e se o seu 
atributo strategy É GenerationType. IDENTITY . Por fim, verificamos se a 
column foi encontrada e se o seu atributo name é id lutador . 


Testando as anotações do atributo nome 


Para testar a metaprogramação do atributo nome , criamos o teste a 
seguir. 


class LutadorTest extends Specification ( 


def '"nome” deve estar anotado com (Column nullable = false, length=30 


'O { 

setup: 

def anotacaoColumn = 
classe.getDeclaredField('nome').getDeclaredAnnotation(Column) 


expect: 
!anotacaoColumn.nullable() 
anotacaoColumn.length() == 30 


// outros testes 


No último teste, criamos um bloco setup para recuperar a anotação 
que queremos verificar junto ao atributo nome ( @column ). No bloco 
expect , Verificamos primeiro se ela foi encontrada e se seu atributo 
nullable é false . Em seguida, verificamos se o seu atributo length é 30 


Testando as anotações do atributo peso 


Para testar a metaprogramação do atributo peso , criamos o teste a 
seguir. 


class LutadorTest extends Specification ( 


def '"peso" deve estar anotado com (Column nullable = false, scale=2 
'O {í 
setup: 
def anotacaoColumn = 
classe.getDeclaredField('peso').getDeclaredAnnotation(Column) 


expect: 
anotacaoColumn.scale() == 2 


// outros testes 


No último teste, criamos um bloco setup para recuperar a anotação 
que queremos verificar junto ao atributo peso ( ecolum ). No bloco 
expect , Verificamos se ela foi encontrada e se seu atributo scale é 2. 


Testando as anotações do atributo nascimento 


Para testar a metaprogramação do atributo nascimento , criamos O 
teste a seguir. 


class LutadorTest extends Specification { 


def '"nascimento" deve estar SEM anotações '() { 
expect: 
Iclasse.getDeclaredField('nascimento').getDeclaredAnnotations() 


// outros testes 


No último teste, criamos um bloco expect apenas para testar se o 
atributo nascimento não possui anotações. 


Conclusão 


Neste capítulo, vimos como criar testes unitários para 
metaprogramação em Java. Com esse tipo de teste, evitaremos 
erros que só poderiam ser percebidos em tempo de execução (ou 
pior, em produção). Também evitamos a criação de complexos 
testes de integração apenas para validar requisitos programados via 
anotações. Com os exemplos que demonstram a facilidade em 
realizar esse tipo de teste, esperamos estimular o leitor a praticá-lo 
com maior frequência e qualidade. No próximo capítulo veremos 
como realizar testes de integração automatizados em projetos 
Spring. 


CAPÍTULO 11 
Testes de integração em projetos Spring 


Spring é um conjunto de bibliotecas e frameworks usados na 
criação dos mais diversos tipos de sistemas na plataforma Java. 
Segundo pesquisa realizada pelo portal Baeldung, a adoção dos 
frameworks Spring é maior que da própria especificação JEE, que é 
a tecnologia oficial da Oracle para sistemas Web e Corporativos 
(vide a próxima figura). 


B Spring 3 ou anterior - 5% 





O Spring 4 - 51% 
O Spring 5 - 24% 






O) Java EE - 9% 





® Outros - 11% 


Figura 11.1: Adoção dos frameworks Spring x JEE. Fonte: http:/www.baeldung.com/java- 
in-2018 


Mesmo entre todos os frameworks fora da JEE, Spring MVC e 
Spring Boot estão na liderança da adoção, segundo pesquisa da 
ZeroTurnaround (vida figura a seguir). Portanto, de acordo com os 
números, é possível notar que existe uma demanda muito grande 
por sistemas para essa tecnologia e, consequentemente, por mais 
testes. 


Web Framework 


30 409 
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Figura 11.2: Adoção dos frameworks Java que não fazem parte da especificação JEE. 
Fonte: https://zeroturnaround.com/rebellabs/spring-and-java-ee-head-to-head/ 


Neste capítulo, focaremos na criação de testes de integração. Isso 
porque para criar testes unitários basta fazer conforme estudamos 
nos diversos capítulos desta obra. Já estudamos o conceito desse 
tipo de teste no capítulo 1. Por que usar Spock framework? . Mas, 
que tal relembrarmos? 


TESTES DE INTEGRAÇÃO 


Usados para testar a integração entre duas ou mais partes do 
programa ou a integração de uma parte do programa a um 
elemento externo (banco de dados, REST API etc.). É um 
complemento aos testes unitários, pois uma parte que funciona 
perfeitamente sozinha não terá, necessariamente, um 
funcionamento perfeito em conjunto com outra(s). Fazendo uma 
analogia com a fabricação de um carro, seria como testar a 
integração entre todas as peças que compõem o câmbio de um 
carro, ou seja, testar o câmbio montado. 





Existe uma relevância muito grande em criar testes de integração 
para essas tecnologias porque elas promovem a integração de 
vários componentes e abstração de várias funcionalidades nos 
projetos em que são usadas. Em um projeto Spring Boot, por 
exemplo, existem componentes e abstrações desde o acesso ao 
banco de dados até exposição de Endpoints em uma REST API. 


Serão usados 2 estudos de caso: um para o Spring Boot e outro 
para Spring MVC. Criar testes de integração para ambos é feito de 
forma muito parecida, pois ambos usam várias bibliotecas Spring 
em comum. O estudo de caso mais completo será do Boot. A seguir, 
no estudo do MVC será demonstrado como testar apenas algumas 
de suas funcionalidades específicas. 


11.1 Spring TestContext framework e Spring 
Module do Spock 


Para facilitar a criação de testes de integração para os frameworks 
Spring foi criado um framework de testes chamado Spring 
TestContext. Ele contém uma série de bibliotecas que permite que 
um teste de integração inicie um contexto completo de uma 


aplicação Spring, dando a possibilidade de testar todos os 
componentes de um projeto de forma integrada. 


Para fazer uso de todas as funcionalidades do Spring TestContext 
em testes com Spock, existe um módulo dele cnamado Spring 
Module. Para usá-lo é preciso adicionar uma dependência ao 
projeto, que consta no código a seguir: 


<dependency> 
<groupId>org.spockframework< /groupId> 
<artifactId>spock-spring</artifactId> 
<version>RELEASE</version> <!-- ou a versão que preferir --> 
<scope>test</scope> 

</dependency> 


Essa dependência, portanto, é necessária para os estudos de caso 
abordados neste capítulo. 


O Spring TestContext framework é muito grande. O objetivo aqui é 
abordá-lo de forma bem básica para compreender como ele foi 
habilitado pelo Spring Module do Spock. Caso queira se aprofundar, 
existe um tutorial completo sobre o Spring TestContext framework 
em sua página no site do Spring em 
https://docs.spring.io/spring/docs/current/spring-framework- 
reference/testing.htmil. 


Existem mais módulos Spock para facilitar a criação de testes de 
integração para outras tecnologias como Guice, Tapestry, Unitils e 
Grails, mas que não fazem parte desta obra. 


11.2 Testes de integração em um projeto Spring 
Boot 


O Spring Boot é um framework muito usado para criar REST APIs, 
possuindo uma série de componentes que abstraem boa parte do 
trabalho repetitivo e perigoso que envolve criar esse tipo de API. 


Resumo do Projeto Spring Boot 


O estudo de caso aqui será um pequeno projeto de cadastro de 
Lutadores de MMA. Esse projeto será constituído por um conjunto 
básico de classes no estilo Entity (JPA) + Repository (Spring) + 
Service (Spring) + Spring REST Controller (Spring), conforme o 
diagrama de classes da figura a seguir. 


-Long id -LutadorService service 

- String nome -LutadorRepository repository 
-double peso -String msgErroCadastro 
-double altura 


-int vitorias 
-int derrotas 
-int nocontest 


+ResponseEntity getLutadorMaisVitorias() 
+ResponseEntity getLutadores() 
+ResponseEntity criarLutadoriLutador lutador) 


+Long getld() 

+void setld(Long id) 

+String getNome() repository 
+void setNome(String nome) D 


+double getPeso() à 
<<interface>> 
LutadorRepository 






+void setPeso(double peso) 
+double getáltura() 

+void setaltura(double altura) 
+int getVitorias() 


+void setVitorias(int vitorias) 

+int getDerrotas() 

+void setDerrotas(int derrotas) 
+int getNocontest() 

+void setNocontest(int nocontest) 


Figura 11.3: Diagrama de classes do projeto de Lutadores de MMA em Spring Boot. 


Classe Lutador (JPA Entity) 


// pacote e imports JPA 


MEntity 
public class Lutador { 


@Id 
@GeneratedValue(strategy=GenerationType.IDENTITY) 
private Long id; 


(OColumn (nullable=false) 
private String nome; 


private double peso; 

private double altura; 
private int vitorias; 
private int derrotas; 
private int nocontest; 


// constutores, getters e setters 


A classe Lutador é uma entidade JPA simples, com um id 
(identificador) de valor gerado com autoincremento e alguns 
atributos simples, sem relacionamento com nenhuma outra 
entidade. O atributo nome é obrigatório. Os demais também são, 
porém, como são de tipos numéricos primitivos, serão inicializados 
com e (zero) automaticamente. Aliás, se você não sabe o que é 
nocontest. resumidamente, é quando não há vencedor nem 
derrotado no combate. Isso pode ocorrer quando a luta termina 
prematuramente ou quando tem seu resultado alterado 
posteriormente. 


Interface LutadorRepository (Spring Repository) 
// pacote e imports Spring 
public interface LutadorRepository extends CrudRepository<Lutador, Long>( 


} 


A interface LutadorRepository é uma extensão de CrudRepository , 
funcionando como um Repository cuja classe de entidade é Lutador e 
a de identificação (chave primária) é Integer. 


Classe Lutadorservice (Spring Service) 


// pacote e imports Spring e JPA 


QService 
public class LutadorService { 


(QAutowired 
private EntityManager em; 


public Lutador findMelhorLutador() { 
return (Lutador) this.em.createQuery( 
"from Lutador order by vitorias desc, nocontest asc, derrotas 
asc") 
.setMaxResults(1) 
.getSingleResult(); 


} 


A classe Lutadorservice está anotada com @service , tornando-a um 
componente do tipo Service do Spring (ou seja, terá uma única 
instância em toda a aplicação). 


Possui apenas um atributo, O em do tipo EntityManager , para que 
possamos realizar operações da JPA nos métodos. Ele será injetado 
em tempo de execução devido à anotação qautowired do Spring. 


Seu método findmelhorLutador() retorna um Lutador . A ideia é retornar 
o lutador com mais vitórias. Em caso de mais de um lutador com o 
mesmo número de vitórias, o primeiro critério de desempate é a 
menor quantidade de nocontest e o segundo é a menor quantidade 
de derrotas. 


Classe Lutadorcontroller (Spring REST Controller) 
// pacote e imports Spring e JPA 


MRestController 
public class LutadorController ( 


(QAutowired 
private LutadorService service; 


(QAutowired 
private LutadorRepository repository; 


0Value("$(msg.erro.cadastro)") 
private String msgErroCadastro; 


// métodos de EndPoints 


A classe LutadorController está anotada com (ORestController , do 
Spring. Isso a torna capaz de abrigar Endpoints da REST API da 
aplicação Spring Boot. 


Os atributos Lutadorservice service € LutadorRepository repository estão 
anotados com qautowired para que sejam injetados pelo Spring em 
tempo de execução, usando a classe e a interface já explicadas 
neste tópico. 


O atributo string msgErroCadastro está anotado com a qvalue do Spring. 
Isso significa que o Spring vai procurar a chave msg.erro. cadastro NO 
arquivo src/main/resources/application.properties (falaremos sobre 
esse arquivo logo mais). Caso encontrada, seu valor será injetado 
em msgErrocadastro em tempo de execução. 


Endpoint GET /melhor-lutador da Lutadorcontroller 
public class LutadorController ( 
// atributos 


(OGetMapping("/melhor-lutador") 
public ResponseEntity getLutadorMaisVitorias() { 
try { 
return ResponseEntity.ok(this.service.findMelhorLutador()); 
} catch (NoResultException e) { 
return ResponseEntity.notFound().build(); 


O método getLutadorMaisvitorias() está anotado com a @GetMapping do 
Spring, o que o configura como método de um Endpoint de URI 
/melhor- lutador cujo verbo HTTP é cer. 


Esse método usa a O service, que é uma instância de Lutadorservice, 
para tentar recuperar o melhor lutador. Caso encontre, devolve uma 
resposta com status 2e0 (Ok) e com um JSON que representa uma 
instância de Lutador. 


Caso não seja encontrado o melhor lutador (caso de base de dados 
vazia), o método fará o Endpoint retornar um status 404 (Not Found!) 
e corpo vazio. 


Endpoint GET / da Lutadorcontroller 
public class LutadorController { 


// atributos 
// método getLutadorMaisVitorias() 


(OGetMapping 
public ResponseEntity getLutadores() { 


return this.repository.count() == QL 
? ResponseEntity.noContent().build() 
: ResponseEntity.ok(this.repository.findAl1l()); 


} 


O método getLutadores() está anotado com a @GetMapping do Spring, O 
que o configura como método de um Endpoint de URI / cujo verbo 
HTTP é cer. 


Esse método usa a repository , que é uma instância de 
LutadorRepository , para tentar recuperar todos os lutadores do banco 
de dados. Caso encontre lutadores, devolve uma resposta com 
status 200 (Ok) e com um JSON que representa uma lista de objetos 
do tipo Lutador . 


Caso não seja encontrado o melhor lutador (caso de base de dados 
vazia), o método fará o Endpoint retornar um status 204 (No Content) 
e corpo vazio. 


Endpoint POST / {JSON} da Lutadorcontroller 


public class LutadorController { 


// atributos 
// método getLutadorMaisVitorias() 
// método getLutadores() 


(OPostMapping 
public ResponseEntity criarLutador ((QRequestBody Lutador lutador) ( 


try { 
this.repository.save(lutador); 
return 
ResponseEntity.status(HttpStatus.CREATED).body (lutador); 
} catch (Exception e) { 
return ResponseEntity.badRequest().body(msgErroCadastro); 


} 


O método criarLutador() está anotado com a @PostMapping do Spring, O 
que o configura como método de um Endpoint de URI / cujo verbo 
HTTP é post . É necessário enviar um corpo na requisição: um JSON 
que represente uma instância de Lutador . 


Esse método usa O repository , que é uma instância de 
LutadorRepository , para tentar inserir o lutador no banco de dados. 
Caso a operação ocorra sem erros, devolve uma resposta com 
status 201 (Created) e com um JSON que representa a instância do 
Lutador recém-salvo no banco. 


Caso ocorra algum erro na operação, o método fará o Endpoint 
retornar um status 40o (Bad request) e o conteúdo de msgErrocadastro 
no corpo da resposta. 


Classe Lutadoresapp (Spring Application) 


QSpringBootApplication 
public class LutadoresApp ( 


public static void main(String[] args) 1 
SpringApplication.run(LutadoresApp.class); 


} 


A classe LutadoresApp está anotada com @SpringBootApplication do 
Spring, o que a torna a classe de aplicação do projeto. Ou seja, ao 
iniciá-la invocando seu método main() , a REST API da aplicação 
entra em funcionamento. 


Arquivo application.properties do projeto Spring Boot 


Além das classes, o projeto também possui um application.properties 
que, por padrão, fica em /src/main/resources . É o nome padrão que o 
arquivo de definição de properties (propriedades) de um projeto que 
usa Spring. Ele será usado para configurar o acesso ao banco de 
dados e uma mensagem que deverá ser obtida no REST Controller 
também no teste de integração. Seu conteúdo está a seguir. 


spring.datasource.url=jdbc:h2:~/lutadores 
spring.datasource.username=sa 
spring.jpa.hibernate.ddl-auto=create 


msg.erro.cadastro=Erro ao tentar o cadastro de Lutador 


O banco de dados que foi configurado é o H2 em memória, mas 
poderia ser o banco de sua preferência. Já a chave msg.erro. cadastro 
é usada para injetar o texto de seu valor na Lutadorcontroller € 
também será usada da mesma forma na classe de testes, sobre a 
qual falaremos a seguir. 


Cenários do teste de integração Spring MVC 


A classe do teste de integração é a Lutadorcontrollertest , que deve 
ficar no diretório padrão de testes, O src/test/groovy . Nela, vamos 


testar os seguintes cenários: 


e Deveria retornar status 204 e sem corpo quando não existirem 
lutadores; 

e Deveria retornar status 400 e mensagem esperada quando 
falha em criar Lutador; 

e Deveria retornar status 201 com JSON correto quando cria um 
Lutador; 

e Deveria retornar 200 trazer todos os lutadores e no formato 
correto quando existirem Lutadores. 


A seguir, vamos analisar o código dessa classe. 


Classe Lutadorcontrollertest (teste de integração com Spring 
Module) 


// pacote e imports Spring e JPA 

OSpringBootTest (classes = LutadoresApp) 

QStepwise 

class LutadorControllerTest extends Specification { 


(OAutowired 
LutadorController controller 


(QAutowired 
LutadorRepository repository 


(QAutowired 
LutadorService service 


(0Value('$(msg.erro.cadastro)') 
private String msgErroCadastro; 


// métodos de teste 
} 


A classe LutadorControllerTest está anotada com 
@org.springframework.boot.test.context.SpringBootTest do Spock. Essa 
anotação indica que a classe deve iniciar um contexto do Spring 


Boot para a realização de testes de integração entre os 
componentes da aplicação. Ou seja, é essa anotação que permite 
testes de integração Spring Boot em uma classe de testes Spock. 


O atributo classes da aspringBootTest deve ser uma classe marcada 
como aplicação Spring Boot, ou seja, uma classe anotada com 
QSpringBootApplication. Por isso, usamos a LutadoresApp Nesse atributo. 


A anotação @Stepwise , já explicada no capítulo 9. Recursos 
avançados foi usada apenas porque a sequência da execução dos 
testes é necessária para o correto funcionamento dos testes de 
integração de nosso exemplo. 


Essa classe possui 3 atributos em comum com a Lutadorcontroller , 
inclusive com as mesmas anotações: repository , service € 
msgErroCadastro . Isso demonstra como a integração será testada só 
com essas declarações: durante a execução dos testes, o Spock vai 
usar o Spring para injetar esses atributos tal como seria feito com o 
projeto Spring Boot. 


O atributo controller está anotado com @Autowired para que também 
tenha seu valor injetado pelo Spring durante a execução dos testes. 
Isso é necessário para que seus atributos gerenciados pelo Spring 
estejam prontos nos testes para que os métodos funcionem durante 
a execução da aplicação Spring Boot. Percebeu como o teste 
promoverá a integração entre os componentes”? 


Cenário Deveria retornar status 204 e sem corpo quando não 
existirem lutadores 


// pacote e imports Spring e JPA 
class LutadorControllerTest extends Specification { 


// atributos 
def 'deveria retornar status 204 e sem corpo quando não existirem 


lutadores'() { 
when: 


def resposta = controller.getLutadores() 


then: 
resposta.statusCode == HttpStatus.NO CONTENT 
lIresposta.body 


// demais métodos de teste 


} 


O teste 'deveria retornar status 204 e sem corpo quando não existirem 
lutadores' () verifica se a resposta Endpoint do método getLutadores() 
da LutadorController terá o status 204 (No Content) com corpo vazio. 
Esse teste é o primeiro a ser executado, logo, a base de dados de 
testes deve estar vazia. 


Cenário Deveria retornar status 400 e mensagem esperada 
quando falha em criar Lutador 


// pacote e imports Spring e JPA 
class LutadorControllerTest extends Specification { 


// atributos 


def 'deveria retornar status 400 e mensagem correta quando falha em 
criar Lutador'() { 
when: 
def resposta = controller.criarLutador(new Lutador()) 


then: 
resposta.statusCode == HttpStatus.BAD REQUEST 
resposta.body == msgErroCadastro 


// demais métodos de teste 


} 


O teste 'deveria retornar status 400 e mensagem correta quando falha em 
criar Lutador' () verifica se a resposta Endpoint do método 
criarLutador() da LutadorcController terá o status 400 (Bad Request) e 


com corpo contendo o valor do atributo msgErrocadastro em caso de 
lutador inválido (no caso foi usado um lutador sem valor em nenhum 
de seus atributos). Vale lembrar que esse atributo está anotado da 
mesma forma que o atributo homônimo na Lutadorcontroller . Ou 
seja, por meio de um teste de integração, verificamos se foi usada a 
injeção planejada na classe que faz o papel de REST Controller. 


Cenário Deveria retornar status 201 com JSON correto quando 
cria um Lutador 


// pacote e imports Spring e JPA 
class LutadorControllerTest extends Specification { 


// atributos 


def 'deveria retornar status 201 com JSON correto quando cria um 
Lutador" () { 
given: 
def lutador = new Lutador(nome: 'Zé Ruela", peso: 80, altura: 1.9) 


when: 
def resposta = controller.criarLutador (lutador) 


then: 
resposta.statusCode == HttpStatus.CREATED 
resposta.body.properties == lutador.properties 


// demais métodos de teste 


} 


O teste 'deveria retornar status 201 com JSON correto quando cria um 
Lutador'() Verifica se a resposta Endpoint do método criarLutador() da 
LutadorController terá o status 201 (Created) e com um JSON de 
resposta cujos atributos são os mesmos de uma instância de Lutador 
. Isso tudo para o caso de um lutador válido. 


Cenário Deveria retornar 200 trazer todos os lutadores e no 
formato correto quando existirem Lutadores 


// pacote e imports Spring e JPA 
class LutadorControllerTest extends Specification { 


// atributos 


def 'deveria retornar 200 trazer todos os lutadores e no formato 
correto quando existirem Lutadores'() { 
given: 
def quantidade = repository.count() 


when: 
def resposta = controller.getLutadores() 


then: 

resposta.statusCode == HttpStatus.OK 
resposta.body.size() == quantidade 
and: 


for (lutador in resposta.body) { 
lutador instanceof Lutador 


// demais métodos de teste 


} 


O teste 'deveria retornar 200 trazer todos os lutadores e no formato 
correto quando existirem Lutadores'() primeiro usa a instância de 
LutadorRepository para consultar junto ao banco de dados quantos 
lutadores estão na tabela. 


A primeira verificação do teste é se o Endpoint do método 
getLutadores() da LutadorController terá o status 200 (Ok). Em seguida, 
é verificado se o corpo da resposta é um JSON cuja quantidade de 
elementos corresponde à quantidade de lutadores no banco de 
dados. 


Ao final, é feita uma verificação que itera no JSON da resposta para 
verificar, item a item, se todos os elementos são compatíveis com 
uma instância de Lutador . 


11.3 Testes de integração em um projeto Spring 
MVC 


O Spring MVC é um framework muito usado para criar projetos Web 
full stack, ou seja, projetos que possuem desde a camada de 
acesso ao banco de dados até os artefatos de front-end. Assim 
como o Boot, possui uma série de componentes que abstraem boa 
parte do trabalho repetitivo e perigoso que envolve criar esse tipo de 
sistema. 


Resumo do Projeto Spring MVC 


Neste estudo de caso, vamos apenas testar um Controller do Spring 
MVC. Os demais componentes ( Service , Repository , Value etc.) 
poderiam ser testados exatamente como fizemos no projeto com 
Spring Boot. 


A classe que será usada como exemplo é a Lutadormvccontroller , 
cujo código está a seguir. 


// pacote e imports do Spring 
QController 
public class LutadorMvcController { 


(OGetMapping("/home") 
public ModelAndView home ((0RequestParam("usuario") String usuario) 


// ações com o argumento 'usuario' 
return new ModelAndView("home"); 


} 


A classe LutadormvcController está anotada com @controller do Spring, 
o que a transforma em um Controller do Spring MVC. É um tipo de 
componente normalmente usado para gerar respostas HTTP com 
páginas HTML no corpo da resposta, mas que também pode gerar 
arquivos binários ou até textos simples. 


O método home() está anotado com a @GetMapping do Spring, O que o 
configura como método de um Endpoint de URI /home cujo verbo 
HTTP é cer . Esse método espera um parâmetro de requisição 
chamado usuario e retorna um modelandview CUja View será a página 
src/main/webapp/WEB-INF/home. jsp . 


O único argumento do método está anotado com a @RequestParam do 
Spring. Isso indica que quem quiser chegar a esse método terá que, 
obrigatoriamente, informar o parâmetro de requisição usuario . 


Arquivo application.properties do projeto Spring MVC 


Além da classe Controller, o projeto também possui um 
application.properties QUe, por padrão, fica em /src/main/resources . 
Ele será usado para configurar o diretório e extensão padrões para 
as views dos Controllers do projeto. Seu conteúdo está a seguir. 


spring.mvc.view.prefix=/WEB-INF/ 
spring.mvc.view.suffix=.jsp 


O valor /weB-INF/ da chave spring.mvc.view.prefix é a partir de 
src/main/webapp . A chave spring.mvc.view.suffix indica a extensão 
padrão para os arquivos de view no projeto. 


Arquivo home.jsp do projeto Spring MVC 


O conteúdo do arquivo src/main/webapp/WEB-INF/home.jsp é até 
irrelevante para nosso estudo de caso. Porém, para deixar o leitor 
mais seguro, segue um exemplo do que poderia estar em seu 
conteúdo. 


<html> 
<body> 
<h2>Bem vindo ao sistema de Lutadores!</h2> 
<div>Que belo sistema de lutadores ;)</div> 
</body> 
</html> 


Cenários do teste de integração Spring MVC 


A classe do teste de integração é a LutadorMvcControllerTest , que 
deve ficar no diretório padrão de testes, O src/test/groovy . Nela, 
vamos testar os seguintes cenários: 


e Deveria retornar status 200 e redirecionar para JSP correto; 
e Deveria retornar status 400 quando parâmetro o usuario não for 
enviado. 


A seguir, vamos analisar o código dessa classe. 


Classe LutadorMvcControllerTest (teste de integração com Spring 
Module) 


// pacote e imports Spring 

QwebMvcTest (LutadorMvcController) 
QContextConfiguration(classes=LutadoresApp) 

class LutadorMvcControllerTest extends Specification { 


(QAutowired 
MockMvc mvc 


(OAutowired 
LutadorMvcController controller 


QValue('$(spring.mvc.view.prefix)') 
String viewPrefix 


// métodos de teste 
} 


A classe LutadorMvcControllerTest está anotada com 
Morg.springframework.boot.test.autoconfigure.web. servlet .WebMvcTest dO 
Spock. Essa anotação indica que a classe deve iniciar um contexto 
do Spring MVC para a realização de testes de integração entre os 
componentes da aplicação. Ou seja, é essa anotação que permite 
testes de integração Spring MVC em uma classe de testes Spock. 


O atributo value da qwebmvcTest deve ser uma classe marcada como 
Controller Spring MVC, ou seja, uma classe anotada com econtroller 


. Por isso usamos a LutadorMvcController nesse atributo. 


A anotação org.springframework.test.context.ContextConfiguration indica 
onde estão as configurações do Spring no projeto. Como criamos 
este estudo de caso no mesmo projeto do estudo de caso com 
Spring Boot, era o caso de usar a Lutadoresapp . Se estivéssemos 
lidando com um projeto Spring MVC à parte, deveríamos indicar 
aqui uma classe com a anotação @configuration do Spring. 


O atributo mockmvc mvc é ator chave nos testes de integração para 
Spring MVC. É com ele que testamos o comportamento dos 
métodos dos Controllers de forma integrada. Por isso ele deve estar 
anotado com qautowired , para que forneça acesso a todos os 
componentes Spring do projeto durante a execução dos testes. 


O atributo LutadormvcController controller é simplesmente o Controller 
que queremos testar. O atributo string viewprefix, anotado com 
@value do Spring será usado para verificar se a view do retorno do 
método a ser testado no Controller está configurada corretamente. 


Cenário Deveria retornar status 200 e redirecionar para JSP 
correto 


// pacote e imports Spring 
class LutadorMvcControllerTest extends Specification { 


// atributos 


def 'deveria retornar status 200 e redirecionar p/ JSP correto'() { 
given: 
def destino = "home" 


when: 
def resposta = 
mvc.perform(MockMvcRequestBuilders.get("/home").param("usuario", "Lady 


Gaga”)) 


then: 
resposta 


.andExpect (MockMvcResultMatchers.status().isOk()) 


. andExpect (MockMvcResultMatchers.forwardedUrl("$(viewPrefix)$g(destino).jsp 


")) 
} 
} 


Aqui, primeiro definimos qual O destino esperado. Em seguida, 
solicitamos a realização da chamada ao método home() de forma 
indireta, indicando o verbo HTTP, a URI e o parâmetro de 
requisição. Na etapa de verificação, primeiro verificamos se o status 
da resposta é 200 (Ok). Em seguida, verificamos se a view 
corresponde a /wEB-INF/ + home + .jsp. 


Cenário Deveria retornar status 400 quando parâmetro O usuario 
não for enviado 


// pacote e imports Spring 
class LutadorMvcControllerTest extends Specification ( 


// atributos 


def 'deveria retornar status 400 quando parâmetro o "usuario" não for 
enviado'() { 
when: 
def resposta = mvc.perform(MockMvcRequestBuilders.get("/home")) 


then: 
resposta.andExpect(MockMvcResultMatchers.status().is(400)) 


} 


Neste teste, solicitamos a realização da chamada ao método nome() 
de forma indireta, indicando o verbo HTTP, a URI e a ausência de 
parâmetros de requisição. Em seguida, verificamos se o status da 
resposta é 400 (Bad Request). Isso porque o parâmetro de 
requisição está como obrigatório em LutadormvcController . 


11.4 Ciclo de vida do contexto Spring nos testes 
de integração 


Quando criamos uma classe de testes de integração usando Spring 
TestContext framework e Spring Module do Spock, é importante ter 

ciência de que cada classe de testes possui seu contexto Spring 
próprio. Isso significa que: 


e Os componentes são compartilhados entre os métodos de 
teste de uma mesma classe, de acordo com o escopo de cada 
componente. Por exemplo: Services são Singletons, portanto 
terão a mesma instância compartilhada entre todos os métodos 
de testes de uma mesma classe. No caso de componentes de 
escopo request, terão uma instância diferente por método de 
uma mesma classe; 


e Os componentes não são compartilhados entre classes de 
testes de integração Spring. Inclusive é possível ver a 
mensagem de inicialização do Spring Boot no log do Maven 
sempre que uma classe de testes de integração é iniciada. 


Esse comportamento está ilustrado na figura a seguir. 


testela() testelb()  testelc() 







ClasseTestel —p» | Contexto Spring da ClasseTestel 


Anotada com Beans Components etc 
mSpringBootTest Services Repositories etc 


teste2a() teste2b() testeZc() 


ClasseTeste2 —p | Contexto Spring da ClasseTesteZ 


Anotada com Beans Components etc 
mSpringBootTest Services Repositories etc 


Figura 11.4: Ciclo de vida de contextos Spring em diferentes testes de integração. 


11.5 Profiles e properties do projeto Spring nos 
testes de integração 


Algumas das funcionalidades que mais dão flexibilidade de 
configuração em projetos com Spring são as profiles (perfis) e 
properties (propriedades), que podem ser configuradas de forma 
muito simples. A seguir, veremos como usar essas funcionalidades 
em testes de integração com Spock. 


Definindo um arquivo de properties para os testes 


É possível definir as properties (propriedades ou configurações) de 
um projeto que usa Spring escrevendo-as em um arquivo chamado 
application.properties (formato Properties, ou seja, chave x valor) ou 
application.yml (formato YAML, ou seja, combinação de listas, mapas 
e valores simples). Nesse arquivo normalmente são definidas 
configurações como: 


e Dados de acesso ao banco de dados; 

e Dados de acesso a outros sistemas (por exemplo: servidor de 
e-mail); 

e Textos de mensagens de validação. 


Por padrão, o Spring procura um desses arquivos no diretório 
/src/main/resources . Porém, imagine que você precisa definir 
configurações apenas para os testes, tais como o uso de um banco 
de dados em memória, por exemplo. Para situações assim, é 
possível definir um arquivo de properties exclusivo para os testes de 
integração. Para isso, basta criar um application.properties (ou . yml ) 
no diretório /src/test/resources , que ele será automaticamente usado 
pelos testes de integração. 


Atenção: caso exista um arquivo de configuração em src/test , OS 
arquivos em src/main serão ignorados durante os testes de 
integração. 


Escolhendo o profile para os testes 


Um dos recursos mais interessantes do Spring é a facilidade em ter 
diferentes profiles (perfis) em um mesmo projeto. Isso permite, por 
exemplo, que a aplicação acesse diferentes bancos de dados, de 
acordo com o profile selecionado. Para que um projeto Spring tenha 
vários perfis configurados, basta que possua vários arquivos de 
properties com nome terminando em -nome_do_perfil . Por exemplo, 
nosso projeto teria vários profiles caso ele tivesse os seguintes 
arquivos em src/main/resources (ou em src/test/resources ): 


e application.properties (profile padrão ) 

e application-test.properties (profile test ) 

e application-dev.properties (profile dev ) 

e application-homol.properties (profile homol ) 
e application-prod.properties (profile prod ) 


Quando criamos uma classe de testes de integração usando Spring 
TestContext framework e Spring Module do Spock, é possível indicar 
o profile que queremos usar na execução de uma classe de testes. 
Para isso, basta usar a anotação 
Morg.springframework. test. context .ActiveProfiles sobre a definição da 
classe de testes. Poderíamos reconfigurar a LutadorcontrollerTest 
deste capítulo para tentar usar um profile chamado test durante a 
execução dos testes de integração. Então ela ficaria como no código 
a seguir. 


// pacote 


import org.springframework.test.context.ActiveProfiles 
// demais imports 


QActiveProfiles("test") 
// demais anotações da classe 
class LutadorControllerTest extends Specification ( 


} 


Com a inclusão da anotação @ActiveProfiles("test") sobre a classe, 
todos os testes nela serão executados considerando as 
configurações no arquivo application-test.properties (ou application- 
test.yml ) em src/test/resources OU €M src/main/resources . 


Ordem de busca de properties conforme profile 


Imagine que você possui várias properties e profiles configurados. 
Ter configurações espalhadas em tantos arquivos pode causar 
confusões durante os testes. 


Para que você tenha certeza de qual arquivo de configuração será 
usado na busca de suas configurações, basta saber qual a 
sequência de arquivos nos quais uma propriedade é buscada pelo 
Spring. Para melhor demonstrar isso, imagine que você solicitou a 
busca pela property msg.erro.sistema e sua classe de testes está 
configurada para o profile test . O Spring tentaria localizar essa 
property nas seguintes sequências durante a execução do teste de 
integração: 


Cenário 1: existe pelo menos 1 arquivo de properties em 
src/test/resources 


1. Arquivo application-test.properties (ou .yml ) em src/test/resources 
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2. Arquivo application.properties (ou .yml ) em src/test/resources . 


Caso a property msg.erro.sistema não seja encontrada em nenhum 
desses 2 arquivos, uma exceção específica do Spring será lançada. 


Cenário 2: não existe nenhum arquivo de properties em 
src/test/resources 


1. Arquivo application-test.properties (ou .yml ) em src/main/resources 
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2. Arquivo application.properties (ou .yml ) em src/main/resources . 


Caso a property msg.erro.sistema não seja encontrada em nenhum 
desses 2 arquivos, uma exceção específica do Spring será lançada. 


Conclusão 


Neste capítulo, vimos como configurar projetos Spring MVC e Spring 
Boot para que seja possível criar testes de integração com Spock 
usando o módulo Spring. Também estudamos um pequeno exemplo 
de teste de integração em cada um deles para demonstrar como 
usar Mocks e a injeção de componentes Spring. No próximo 
capítulo, será ensinado como criar testes de unidade em projetos 
Android. 


CAPÍTULO 12 
Testes unitários em projetos Android 


A plataforma Android é líder mundial no mercado de smartphones 
desde 2011, chegando a contar com quase 90% de participação em 
meados de 2017 (vide figura a seguir). Isso leva a uma demanda 
muito grande por aplicativos para essa plataforma, 
consequentemente, por mais testes também. 
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Figura 12.1: Participação do Android no mercado de Smartphones. Fonte: 
https://www.statista.com/statistics/266136/global-market-share-held-by-smartphone- 
operating-systems/ 


Outro fato relevante: segundo o portal javalibs.com, cerca de 25% 
dos repositórios do GitHub que possuem o Spock como 
dependência são projetos para Android, como ilustra a próxima 
figura. Ou seja 1 em cada 4 projetos que usam Spock o usa para 
testar código Android. 
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EH android (25%) 


Figura 12.2: Distribuição das dependências de Spock entre "Android" e "Não Android". 
Fonte: https://javalibs.com/artifact/org.spockframework/spock-core 


Neste capítulo, veremos quais os passos para configurar um projeto 
dessa plataforma para que seja possível criar e executar testes 
unitários com Spock. 


12.1 Estudo de caso 


Para demonstrar a criação de testes unitários para Android com 
Spock, vamos usar como exemplo uma miniaplicação que possui as 
seguintes características: 


e Possui apenas 1 Activity; 

e A tela possui 2 EditText que só aceitam números; 

e Atela possui um Button que, ao ser clicado, tenta realizar uma 
divisão entre os números digitados nas EditText. Caso o 
segundo número seja o (zero), a divisão não deve ocorrer; 

e A tela possui uma Text que receberá o resultado da divisão ou a 
mensagem de erro em caso de segundo número de valor o. 


O código do arquivo XML do layout da Activity está a seguir. 


<EditText android:id="(+id/editNuml"/> 
<EditText android:id="(+id/editNum2"/> 


<Button 
android: text="Somar” 
android: id="GQ+id/btnDividir" 
android:onClick="dividir"/> 


<TextView android:id="(+id/tvResultado"/> 


No código do XML do layout, deixamos apenas o código dos 
componentes de tela com os atributos mais relevantes para nosso 
exemplo. Foram omitidos atributos de estilos e posicionamento. 
Note que há um onclick NO Button . O método dividir usado nele está 
no código da classe Java da Activity ( Telatnicial ), a seguir. 


// pacote e imports 
public class TelaInicial extends AppCompatActivity { 


// Declaração dos componentes EditText editNum1i, editNum2 e TextView 
tvResultado; 
// onCreate instanciando os 3 componentes 


public void dividir(View botao) { 


Double numero1l = 
Double.valueOf(this.editNumi.getText().toString()); 

Double numero? = 
Double.valueOf(this.editNum2.getText().toString()); 


this.tvResultado.setText( 
(numero2 == 0) ? "Não sei dividir por O" : (numerol / 
numero2)+" "3; 


No código da classe Java da Activity temos o método dividir(view 
botao) que é o método associado ao onclick do botão de identificação 
a+id/btnDividir do layout. É esse método que que vamos testar em 
nosso exemplo. 


12.2 Configurando um projeto Android para 
trabalhar com Groovy 


A plataforma Android possui três linguagens de programação 
oficiais: Java, C++ e, a mais recentemente figurante nessa lista, 
Kotlin. Isso não se torna impedimento para que possamos 
configurar o uso de Groovy no escopo de testes. A seguir, os 
passos necessários para que possamos usar a linguagem oficial do 
Spock em um projeto Android. 


Solicite o uso do plugin groovy 


O primeiro passo é configurar o Gradle do projeto para trabalhar 
com a linguagem Groovy no código-fonte. No build.gradle do 
diretório raiz do projeto, inclua o uso do plugin groovy . Basta 
adicionar a linha a seguir no início do arquivo. 


apply plugin: 'groovy' 


Ratificando: o local da inclusão desse código é O <diretório raiz do 
projeto>/build.gradle . 


Adicione o Gradle Plugin For Groovy On Android no classpath 
do projeto 


Uma vez que configuramos o Gradle do projeto para trabalhar com 
Groovy, precisamos adicionar o suporte a Groovy nos builds de 
projetos Android. Para isso é necessário o Gradle Plugin For Groovy 
On Android. Para adicioná-lo ao classpath do projeto, basta incluir o 
seguinte trecho de código no build.gradle do diretório raiz do projeto: 


buildscript { 
// repositories ... 


dependencies { 
// demais configurações 


classpath 'org.codehaus.groovy:groovy-android-gradle-plugin:2.0.0' 


} 


Ratificando: o local da inclusão desse código é O <diretório raiz do 
projeto>/build.gradle . 


A versão usada nesta aqui foi a 2.0.0 que era a mais atual, mas você 
pode usar outra versão conforme sua necessidade ou preferência. 
Mas com este passo, apenas adicionamos uma dependência 
necessária no classpath, isso ainda não configurou o projeto 
Android para trabalhar com Groovy! A seguir, vejamos como usar o 
plugin que essa dependência traz. 


Solicite o uso do plugin groovyx.android 


Após adicionar sua dependência no classpath do projeto, é 
necessário solicitar explicitamente o uso do plugin de Groovy para 
Android. Basta incluirmos a seguinte linha no início do arquivo 
/app/build.gradle . 


apply plugin: 'groovyx.android' 


Ratificando: o local da inclusão desse código é O <diretório raiz do 
projeto>/app/build.gradle. 


O uso desse plugin permite criar e compilar classes Groovy em 
projetos Android. Elas devem ser criadas nos diretórios 
app/src/main/groovy (projeto) € app/src/test/groovy (testes unitários). Só 
com essas configurações, já poderíamos, por exemplo, criar testes 
JUnit escritos em Groovy no diretório app/src/test/groovy do projeto. 


Incluir o Spock como dependência do módulo app 


O último passo é incluir o Spock como dependência do módulo app 
do projeto. Basta incluir as seguintes dependências no arquivo 
/app/build.gradle . 


dependencies { 
// dependências já existentes 


testImplementation 'org.spockframework:spock-core:1.1-groovy-2.4' 
testImplementation 'org.objenesis:objenesis:2.5.1' 
testImplementation 'net.bytebuddy:byte-buddy:1.6.5' 


} 


Ratificando: o local da inclusão desse código é O <diretório raiz do 
projeto>/app/build.gradle. 


O escopo testImplementation equivale ao test do Maven, portanto, o 
Spock, o Groovy e as demais dependências não farão parte do 
aplicativo do projeto, não impactando, portanto, em queda de 
desempenho. 


Quanto às duas dependências após a do Spock, como já vimos no 
capítulo 7. Testando com a ajuda de Mocks, as dependências 
objenesis € byte-buddy SãO necessárias apenas caso precisemos 
trabalhar com Mocks. 


Após incluir essas dependências e plugins, basta sincronizar o 
Gradle do projeto para que o Android Studio faça o download das 
bibliotecas que estão faltando para o uso de Groovy no projeto. 


Criar o diretório de testes unitário groovy 


Após a configuração das dependências e plugins e sincronização do 
Gradle, crie o diretório groovy em app/src/test . O Android Studio 
automaticamente tratará esse diretório como de código-fonte de 
testes ao identificar o uso do plugin de Groovy para Android no 
projeto. 


12.3 Testando o projeto Android 


Para testar a classe TelaInicial , Criamos a TelaInicialTest em 
/app/src/test/groovy/<pacote da aplicação>/ . O início de seu código- 
fonte está na sequência. 


// pacote e imports 
class TelaInicialTest extends Specification { 


TelaInicial telaInicial 
EditText editNumi 
EditText editNum2 
TextView tvResultado 


// métodos de teste 


O objeto telatnicial é o alvo de nossos testes. Os demais objetos, 
todos componentes de tela Android, serão instanciados com Mocks. 
A inicialização de todos será no método setup() , cujo código segue. 


class TelaInicialTest extends Specification ( 


// atributos 


def setup() { 
telaInicial = new TelaInicial() 


editNumi = Mock(EditText) 
editNum2 = Mock(EditText) 
tvResultado = Mock(TextView) 


editNumi.getText() >> Mock(Editable) 
editNum2.getText() >> Mock(Editable) 


telaInicial.editNumi = editNumi 
telaInicial.editNum2 = editNum2 
telaInicial.tvResultado = tvResultado 


Note que instanciamos o objeto Telatnicial telaInicial com um 
construtor padrão, pois, como é o alvo de nosso teste, não pode ser 
um Mock. Em seguida, iniciamos os componentes de EditText €e 
TextView com Mocks. Também configuramos como sendo Mocks os 
retornos dos métodos getText() dos EditText . Por fim, alteramos os 
atributos editNum1 , editNum2 € tvResultado pelos homônimos de nossa 
classe de teste. Com essas ações no setup() , todos os métodos 
desta classe poderão usar uma instância de TelaInicial pronta para 
passar por testes. 


A seguir, vejamos como seria um teste que verifica se a divisão do 
método dividir(View botao) é feita de forma correta. 


class TelaInicialTest extends Specification { 
// atributos e setup() 


def 'deveria dividir'(O { 
given: 
def numerol = 10 
def numero? = 20 
editNumi.text.toString() >> numerol.toString() 
editNum2.text.toString() >> numero2.toString() 


when: 
telaInicial.dividir(Mock(Button)) 


then: 
1 * tvResultado.setText((numero1/numero2).toString()) 
} 


No bloco given do teste deveria dividir() , criamos 2 números para 
serem usados na execução e verificação do teste. Em seguida, 
fazemos com que OS EditText cheguem ao momento da execução do 
teste como se contivessem esses números como seus conteúdos. 
No bloco when invocamos o método de teste com um Mock de um 
Button . Por fim, no bloco then , verificamos se o método setText() do 
tvResultado foi executado só 1 vez e com o valor correspondente à 
divisão entre os 2 números usados no teste. 


O próximo código-fonte contém o teste 'não deveria dividir por 
zero'() , que verifica se, de acordo com o requisito descrito, a divisão 
não ocorre quando o segundo número é O (zero) e, em vez disso, é 
exibida a mensagem Não sei dividir por 0. 


class TelaInicialTest extends Specification ( 
// atributos, setup() e 'deveria dividir'() 


def 'não deveria dividir por Zero'() { 
given: 
editNuml.text.toString() >> "10" 
editNum2.text.toString() >> "0" 


when: 
telaInicial.dividir(Mock(Button)) 


then: 
1 * tvResultado.setText("Não sei dividir por 0") 


} 


No bloco given do teste não deveria dividir por Zero(), fazemos com 
que OS editNum1 € editNum2 cheguem ao momento da execução do 
teste como se contivessem esses números 18 € o como seus 
conteúdos, respectivamente. No bloco when invocamos o método de 
teste com um Mock de um Button . No bloco then , verificamos se o 
método setText() dO tvResultado foi executado só 1 vez e com a frase 
Não sei dividir por 0. 


Como vimos no pequeno exemplo aqui descrito, é possível criar 
testes unitários para a plataforma Android usando Spock, inclusive 
usando Mocks, bastando poucas configurações. 


12.4 Limitações do Spock no Android 


Infelizmente, há uma limitação do uso de Spock na criação de testes 
automatizados para Android: não é possível criar testes de 
instrumentação, ou seja, testes que ficam no diretório 
/app/src/androidTest . 


TESTES DE INSTRUMENTAÇÃO DA PLATAFORMA ANDROID É um 
tipo de teste que é executado diretamente no dispositivo ou 
emulador e testa como o aplicativo vai se comportar durante a 
execução. O Android Studio o instala e só depois executa os 
testes. São usados para testar o comportamento dos 


componentes Android, como telas, botões etc. Também ajudam 
a testar a interação, o ciclo de vida e os estados dos 
componentes. 


São aqueles testes que ficam no diretório /app/src/androidTest . 





Conclusão 


Neste capítulo, vimos como configurar um projeto Android para que 
seja possível criar testes unitários com Spock. Também estudamos 
um pequeno exemplo de teste unitário com Mocks e deixamos claro 
que não é possível criar testes de instrumentação com Spock em 
projetos Android. 


CAPÍTULO 13 
Apêndice A - Guia de Groovy para 
desenvolvedores Java 


Groovy é a linguagem oficial do Spock framework, por isso é 
fundamental ter uma proficiência mínima com ela. Este capítulo é 
para o leitor que possui pouca ou nenhuma experiência coma essa 
linguagem. É um guia focado em desenvolvedores Java, para que 
façam o "de x para" (em Java é daquele jeito e em Groovy é desse) 
e tenham maior facilidade na escrita dos testes com Spock. 


13.1 Como funciona o Groovy 


A linguagem Groovy foi criada em 2003 por James Strachan e hoje 
possui seu código aberto sendo mantida pela Apache Software 
Foundation desde 2015. É uma das linguagens cujo compilador gera 
arquivos executáveis pela Máquina Virtual Java, a JVM. Ou seja, 
arquivos escritos nessa linguagem, quando compilados, geram 
arquivos .class executáveis por qualquer JVM de versão de Java 
compatível. Na prática, isso significa que: 


e Se uma IDE possui suporte a Java e Groovy, as classes 
escritas nessas duas linguagens conseguem trabalhar entre si 
de forma transparente; 

e Bibliotecas escritas em Groovy podem ser usadas por projetos 
Java e vice-versa. 


Esse funcionamento é representado na figura a seguir. 








Fabricante.groovy Veiculo.java 
class Fabricante { public class Veiculo { 
// atributos private Fabricante fabricante; 
/ demais atributos 
/ métodos 
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Figura 13.1: Funcionamento do Groovy na JVM. 


É por isso que o Spock, que possui como linguagem de 
programação o Groovy, pode ser usado para criar testes para 
projetos em Java, Scala, Kotlin, Jython, JRuby ou qualquer outra 
linguagem que compile para a JVM. Consequentemente, também é 
possível criar testes para projetos que usam qualquer framework 
Java como Spring MVC/Boot, Play, Struts, VRaptor etc. e até 
mesmo para projetos Android. 


Uma característica que reduz a “curva de aprendizado" dessa 
linguagem para desenvolvedores Java é a proximidade entre as 
sintaxes e a possibilidade de escrever um código Groovy 
exatamente como escreveria em Java, que vai compilar e funcionar 
perfeitamente na imensa maioria dos casos. Ou seja, na dúvida em 
determinado trecho de código Groovy, faça exatamente como faria 
em Java. 


13.2 Características e recursos do Groovy 


A seguir, alguns dos recursos e características do Groovy que 
podem ajudar muito na criação de testes com Spock. 


Diferenças na sintaxe 


A sintaxe do Groovy é muito parecida com do Java. Porém, algumas 
diferenças na sintaxe do Groovy podem melhorar a produtividade no 
desenvolvimento. A seguir, várias dessas diferenças serão 
apresentadas. 


Ponto e vírgula são opcionais no final da linha de código 


Caso o desenvolvedor queira abrir mão de usar ponto e vírgula (;) 
ao final de cada linha, o compilador Groovy vai considerar a quebra 
de linha como o fim da linha de código. Porém, se ela for utilizada, 
será o final explícito da linha de código, como é em Java. É possível 
usar linhas com e sem ponto e vírgula no final em um mesmo 
arquivo Groovy sem problema algum. 


System.out Opcional 


Caso seja necessário imprimir algo na saída padrão, é possível usar 
OS System.out.print() € System.out.printin() como em Java. Porém, 
como o system.out é opcional em Groovy, podem ser substituídos 
apenas por print() € printIn() , respectivamente. 


Parênteses são opcionais na invocação de métodos 


Em Groovy, não é obrigatório o uso de parênteses na invocação de 
métodos, sejam eles com ou sem parâmetros. Como exemplo, 
temos o código a seguir, que imprime textos na saída padrão 
usando O printIn com e sem parênteses. 


printin("Não sou dono do mundo") 
println "Mas sou filho do dono" 


Outro exemplo: o código a seguir exemplifica a invocação de 
métodos da classe java. lang.Math sem parênteses, primeiro com um 
depois com dois parâmetros. 


double raizl44 = Math.sgrt 144 // retornará a raiz de 144: 12 
double doisAoCubo = Math.pow 2,3 // retornará 2 ao cubo: 8 


Ratificando: o não uso de parênteses é opcional. Caso o leitor ache 
esse tipo de sintaxe confusa, pode usar os parênteses tal como usa 
na invocação de métodos em Java. 


Por padrão, as classes são públicas 


Quantas vezes você criou uma classe que não deveria ser public ? 
Em Groovy, as classes são públicas por padrão. Ou seja, a classe 
Futebolista a seguir será compilada como pública pela JVM: 


// Futebolista.groovy 
class Futebolista ( // em tempo de execução: "public class Futebolista" 
// atributos, métodos etc. 


} 


Por padrão, os atributos são privados 


Quantas vezes você criou um atributo de instância que não deveria 
ser private ? Em Groovy, os atributos são privados por padrão. Ou 
seja, na classe Groovy Futebolista a seguir, os atributos nome e 
valorPasse Serão considerados privados pela JVM: 


// Futebolista.groovy 
class Futebolista { 
String nome // em tempo de execução: "private String nome" 
double valorPasse // em tempo de execução: “private double valorPasse" 


} 
Por padrão, os métodos são públicos 


Você criou muito mais métodos public, private OU default em suas 
classes? Em Groovy, os métodos são públicos por padrão. Ou seja, 


a classe Groovy Futebolista a seguir teria um método considerado 
público ( treinar() ) e outro privado ( fugirDaconcentracao() ) pela JVM: 


// Futebolista.groovy 
class Futebolista { 
String nome 
double valorPasse 


void treinar() { // em tempo de execução: "public void treinar()" 
// treinando... 


private void fugirDaConcentracao() { 
// fazendo a festa fora da concentração... 


} 
} 


É possível atribuir valores de atributos na criação de objetos 


Em Java, quando queremos criar uma instância que já tenha 
determinados valores em atributos, é necessário criar construtores 
para isso. Em Groovy, toda classe possui um construtor que aceita 
um map como argumento (porém, com colchetes opcionais). Assim, é 
possível indicar os argumentos que quiser e seus valores. Por 
exemplo, seria possível instanciar um objeto do tipo Futebolista como 
no código a seguir: 


def jogadorA = new Futebolista(nome: 'Ze Boleiro', valorPasse: 100) 
def jogadorB = new Futebolista(valorPasse: 100, nome: 'Ze Boleiro') 
def jogadorC = new Futebolista(nome: 'Ze Boleiro') 

def jogadorD = new Futebolista(valorPasse: 100) 


def jogadorE = new Futebolista([nome: 'Ze Boleiro', valorPasse: 100]) 


Map mapaloko = // Map criado em algum lugar... 
def jogadorF = new Futebolista(mapaLoko) 


Métodos podem ter uma frase entre aspas como nome 


Em classes de testes automatizados, normalmente um método testa 
um cenário. Imagine um cenário chamado "o valor do passe do 
jogador não pode ser menor ou igual a O(zero)". Se fôssemos 
nomear um método da maneira convencional, ou seja, uma palavra 
só em camelCase, seu nome seria algo como... 


def valorPasseJogaodorNaoAceitaZeroOuMenos() { ... } 


Não acha que é um nome longo e difícil de ler? Uma alternativa 
seria reduzir o nome e pôr a descrição do cenário no JavaDoc do 
método. Porém, caso o teste falhe, é seu nome que é impresso no 
log da execução dos testes. 


Usando Groovy, o nome do método poderia ser... 


def 'valor do passe do jogador não pode ser menor ou igual a 0'() { ... } 


Usando esse recurso, o cenário do teste fica literalmente descrito no 
nome do método. Outra vantagem é que se o teste falhar, o log de 
execução conterá os cenários e não nomes de métodos longos e/ou 
difíceis de ler. 


Podem ser usadas aspas simples ou duplas e até mesmo 
caracteres especiais (letras acentuadas, cê-cedilha etc.) podem ser 
usados. 


A tipagem pode ser estática ou dinâmica 


Para reduzir o tempo de programação, em Groovy é possível criar 
objetos e métodos com o operador def , usando o recurso da 
tipagem dinâmica. Em caso de métodos, é possível omitir o tipo 
dos parâmetros. Vejamos exemplos a seguir. 


No exemplo a seguir, foi usada a tipagem dinâmica para ambos os 
métodos. Em tempo de execução, a JVM vai considerar que eles 
retornam Object. 


def metodoX(p1, p2) { // em tempo de execução: "public Object 
metodoX(Object p1, Object p2)" 


ft return sses 


def metodoY(def n1, def n2) { // em tempo de execução: "public Object 
metodoY(Object n1, Object n2)" 
[1 Peturh és) 


} 


Se o método for static , até mesmo o def é opcional, como nos 
exemplos a seguir, cujos métodos serão considerados públicos, 
estáticos e com retorno Object em tempo de execução: 


static metodoX(p1, p2) { // em tempo de execução: "public static Object 
metodoX(Object p1, Object p2)" 
// return ...; 


static def metodoY(def n1, def n2) { // em tempo de execução: "public 
static Object metodoY(Object n1, Object n2)" 
[I retürn sus) 


} 


Se o desenvolvedor preferir, pode deixar a declaração do método ou 
dos argumentos estática, como nos exemplos a seguir: 


Double metodoX(n1, n2) { // em tempo de execução: "public Double 
metodoY(Object n1, Object n2)" 
// return quai 


Double metodoY(Double n1, n2) { // em tempo de execução: "public Double 
metodoY (Double n1, Object n2)" 
// return ss.) 


void metodoZ(Double n1, Double n2) { // em tempo de execução: "public 
void metodoZ(Double n1, Double n2)" 
fI peturm sses 


Objetos também podem ser definidos com esse recurso, como no 
exemplo a seguir onde primeiro é criado um BigDecimal declarado 
com tipagem dinâmica e, depois um outro com tipagem estática. 


def numeroð = new BigDecimal(0) // em tempo de execução: BigDecimal 
numeroO =... 
BigDecimal numero1 = new BigDecimal(1) 


Uma boa notícia para o desenvolvedor é que as principais IDEs 
Java do mercado - Eclipse, IntelliJ e NetBeans - sugerem os 
métodos e atributos do tipo usado na instanciação. Ou seja, no 
último código, após numeroo. essas IDEs iriam sugerir métodos e 
atributos da classe BigDecimal . 


Operador == faz o papel do .equais() 


Em Java, o operador == verifica se os membros comparados são, 
literalmente, o mesmo objeto, a mesma instância. Para saber se 
possuem conteúdo igual, deve-se usar o método .equals() . Inclusive 
é comum que iniciantes em Java tentem comparar duas Strings de 
mesmo conteúdo com == e acabam recebendo um false como 
resultado. 


Acreditando que a maioria dos desenvolvedores faz muito mais 
comparação de conteúdo do que de referência de instância em seus 
projetos, os arquitetos da linguagem Groovy definiram que, nela, o 
== correspondesse ao .equals() do Java. Vejamos o exemplo a 
seguir, onde texto1 € textoz têm seus conteúdos comparados: 


String textoli = // valor recebido em tempo de execução 

String texto2 = // valor recebido em tempo de execução 

def teste = textol == texto? 

// se o conteúdo de "textol" e "texto2” forem iguais, "teste" será 
"true" 


Caso exista a necessidade de saber se dois objetos são a mesma 
instância, deve-se usar o método .is() , conforme o exemplo a 
seguir: 


String textol = // valor recebido em tempo de execução 
String texto2 = // valor recebido em tempo de execução 
String texto3 = texto1 

def testele2 = textol.is(texto2) // "false" 

def testele3 = textol.is(texto3) // “true” 


Concatenação de valores String mais dinâmica e simples 


Em Groovy, um objeto string pode ser instanciado com aspas 
simples, como no exemplo a seguir: 


String poema = 'Nas curvas do teu corpo capotei meu coração” 


Porém, ao se fazer isso, perde-se a possibilidade de usar a 
capacidade de concatenações dinâmicas do Groovy, que só é 
possível quando se usa aspas duplas. Basta usar o operador ge o 
nome do objeto a ser concatenado no texto. Vejamos o exemplo a 
seguir, onde time1 , timez € dias serão concatenados no conteúdo de 


anuncio : 


def time1 = 'Tabajara' 

def time? = 'Sayajins' 

def dias = 7 

def anuncio = "O jogo será entre $timel e $time2. Faltam $dias dias, não 
percam!" 

// "O jogo será entre Tabajara e Sayajins. Faltam 7 dias, não percam!" 


A montagem de um texto pode incluir resultados da invocação de 
métodos e/ou de operações matemáticas. Assim como o recurso 
anterior, é possível executar métodos e operações matemáticas e 
concatenar seus resultados em String Groovy. Nesse caso, a 
expressão deve estar dentro de ${}. 


No exemplo a seguir, o resultado de touppercase() em time1 e de 
substring(4) Sobre timez , bem como o resultado de valor dividido por 
2 serão concatenados no conteúdo de anuncio . 


def timel = 'Tabajara' 
def time? = 'Sayajins' 
def valor = 20 


def anuncio = "O jogo será entre $(timei.toUppercCase()+ e 
$(time2.substring(4)). Mulheres pagam $(valor/2), não percam!" 
// "O jogo será entre TABAJARA e jins. Mulheres pagam 10, não percam!" 


Caso exista a necessidade de montar um texto que deva estar tão 
associado a um objeto ao ponto que seu conteúdo acompanhe 
alterações feitas nesse objeto, pode-se lançar mão de outro tipo de 
concatenação mais dinâmica ainda, verificando o valor atual de 
um objeto sempre que a String for invocada. Para isso, o objeto 
deve estar dentro de ${->}. 


No código do próximo exemplo, associamos time1 € timez a anuncio de 
tal forma que, sempre que anuncio for usada, seu conteúdo pode 
variar, de acordo com o conteúdo de time1 € timez. 


def time1 = 'Tabajara' 

def time? = 'Sayajins' 

def frase = "O jogo será entre $(-> timel) e $(-> time2)" 
// nesse momento, “anuncio” é 

// "O jogo será entre Tabajara e Sayajins” 


time1 = 'Remo' 

time2 = 'Paysandu' 

// a partir desse momento, “anuncio” passa a ser 
// "O jogo será entre Remo e Paysandu” 


String podem ter múltiplas linhas sem concatenações 


Quem já precisou escrever uma instrução SQL ou criar um Mock de 
um JSON em Java já deve ter feito todo tipo de malabarismo para 
que uma String de várias linhas não fique tão ilegível no código. Em 
Groovy, existe o recurso de múltiplas linhas. Basta usar três aspas 
simples ou duplas para instanciar uma String. 


No exemplo de String de múltiplas linhas a seguir, é criada uma 
instrução SQL com 3 linhas. 


def consultaTimesSemTitulo = ''' 
select * from tb time 
where num titulos = 0 


order by dt cricao desc 


Caso você precise criar uma String de múltiplas linhas com 
concatenação de métodos e/ou operações matemáticas, basta usar 
três aspas duplas nos limites da String. O exemplo a seguir monta 
uma instrução SQL de múltiplas linhas concatenando seu conteúdo 
com uf. 


def uf = "AM' 
def consultaTimesAmazonas = 


select * from tb time 
where estado = $(uf) 


Interoperabilidade com classes Java 


A interoperabilidade de Groovy com classes Java é total, contanto 
que as versões de Java usadas na compilação de ambos sejam 
compatíveis. Trata-se da mesma restrição entre classes de arquivos 
escritos em Java. 


Para exemplificar essa interoperabilidade, consideremos a classe 
Java apploko.pjava.Futebolista , que contém três atributos simples, um 
construtor que altera todos eles e seus getters e setters: 


package apploko.pjava 
// imports 


public class Futebolista ( 
private String nome; 
private double habilidade; 
private double velocidade; 


public Futebolista(String nome, double habilidade, double velocidade) { 
// atribuições simples 


} 


// getters e setters públicos de todos os atributos 


} 


A classe Groovy FutebolistasLokos a seguir usa a classe Java 
apploko.pjava.Futebolista de forma transparente: uma instância é 
criada usando seu construtor e um de seus métodos, O setNome() , é 
invocado. 


import apploko.pjava.Futebolista 
// demais imports 


class FutebolistasLokos { 
Futebolista createHabilidoso() { 
def habilidoso = new Futebolista("Romário”, 95, 90) 
habilidoso.setNome("Romário 11") 
return habilidoso 


} 
} 


Se o projeto utilizar Maven ou Gradle, qualquer classe das 
dependências também será acessível de forma transparente pelas 
classes Groovy. 


NullPointerException é muito fácil de ser evitado 


Se o leitor já trabalha com Java há algum tempo já deve ter visto o 
java. lang.NullPointerException (vulgo NPE) várias vezes quando 
executava seu projeto. Isso ocorre quando tentamos invocar um 
método de um objeto nulo ( nu11 ), o que acontece com uma certa 
frequência porque é muito trabalhoso (e fácil de esquecer) verificar a 
cada getXXX() se não temos um nu11 . Em Groovy esse problema é 
simples de resolver, pois existe o chamado operador de 
navegação segura (Safe navigation operator), que previne o NPE 
apenas com o uso de ? antes do . . Vide o próximo código. 


def jogador = // instanciado em tempo de execução a partir do banco de 
dados, por exemplo 
def pais = jogador?.getTime()?.getPais()?.getNome(); 


No último código, Caso jogador OU getTime() OU getPais() seja null, O 
objeto pais simplesmente receberá nu11 , sem NPE. Caso o operador 
? não seja usado, o risco de NPE é o mesmo de uma classe Java. 


Manipulação de coleções é muito simples 


A manipulação de coleções em Java é considerada verbosa demais 
por desenvolvedores acostumados com linguagens como PHP, 
Python, Ruby e JavaScript. Em Groovy, a manipulação de coleções 
é bem simples, se comparada com Java, conforme apresentado a 
seguir. 


Criando uma coleção com valores Em Java, para criar uma 
coleção com valores deve-se recorrer a classes utilitárias, sejam 
elas do Java ou de bibliotecas de terceiros. Em Groovy, esse tipo de 
operação é muito simples, como nos exemplos a seguir. No próximo 
código, há um exemplo da criação de uma List em Groovy. Ele cria 
uma instância de arrayList com 4 (quatro) elementos. 


def posicoes = ['goleiro', 'zagueiro', 'meia', 'atacante'] 


O interessante no código anterior é que as IDEs Eclipse e IntelliJ 
inferem o tipo de objeto da coleção quando se cria uma usando 
todos os elementos do mesmo tipo. Assim, quando tentar a 
recuperação de elementos dessa coleção, a IDE exibirá que o 
retorno seria do tipo string . Caso não consigam fazer a inferência, a 
coleção será tratada como de object . 


No próximo código, há um exemplo da criação de um map em 
Groovy. Ele cria uma instância de Hashmap com 3 (três) elementos, 
com as chaves derrotas , empates € vitorias cujos Valores são 0,1€3, 
respectivamente. 


def campanha = ['derrotas': O, 'empates': 1, 'vitorias': 3] 


Um detalhe bem útil em Groovy é a possibilidade de ser opcional o 
uso de aspas quando as chaves do mapa são string . Portanto, no 


código todas as três chaves poderiam estar sem aspas, como no 
código a seguir. 


def campanha = [derrotas: O, empates: 1, vitorias: 3] 


Criando coleções vazias Em Java, para criar uma coleção vazia, 
devemos usar construtores como faríamos para qual outro tipo de 
classe. Em Groovy, é possível usar os mesmos construtores, porém 
as principais coleções podem ser criadas com o uso de operadores, 
como nos exemplos a seguir. 


No código Groovy adiante há um exemplo de criação de List vazia, 
implementada como ArrayList . 


def posicoes = [] 


No código a seguir há um exemplo de criação de map vazia 
implementada como Hashmap em Groovy. 


def pontuacoes = [:] 
Adicionando um elemento a uma coleção 


Em Java, para adicionar elementos a uma coleção devemos 
recorrer a métodos, como add() OU put() . Em Groovy é possível usar 
exatamente os mesmos métodos, porém também é possível usar 
operadores, como nos exemplos a seguir. 


No próximo código, há um exemplo da criação de uma List vazia e 
posterior inclusão de elementos nela. 


def posicoes = [] 
posicoes += 'goleiro' 
posicoes += 'zagueiro' 


Há três maneiras de incluir um elemento num map em Groovy, todas 
exemplificadas no código a seguir. 


def campanha = [:] 
campanha.derrotas = 0 // chave: 'derrota' / valor: O 


campanha[ 'empates'] = 1 // chave: 'empate' / valor: 1 
campanha += [vitorias: 3] // chave: 'virotia' / valor: 3 


Recuperação de itens de uma coleção Em Java, para recuperar 
um item de uma coleção devemos recorrer a métodos, como O get() 
. Em Groovy é possível usar exatamente os mesmos métodos, 
porém também é possível usar operadores, como nos exemplos a 
seguir. 


No próximo código, há exemplos da recuperação de um elemento 
de uma List. 


def posicoes = ['goleiro', 'zagueiro', 'meia', 'atacante'] 
println(posicoes[0]) // imprimiria 'goleiro' 
println(posicoes[2]) // imprimiria 'meia' 


Há duas maneiras de recuperar um elemento de um map em Groovy, 
exemplificadas no código a seguir. 


def campanha = [derrota: O, empate: 1, vitoria: 3] 
campanha.derrota // © 
campanhal[ 'vitoria'] // 3 


Recuperando o último elemento de uma lista ou vetor 


Imagine que você precise do último elemento em uma lista mas não 
sabe quantos elementos ela conterá no momento em que precisar 
dessa informação. Em Java é preciso verificar o tamanho da lista e 
usar seu valor menos 1 para recuperar o último elemento de uma 
lista. Em Groovy, há um método chamado 1ast() que abstrai isso e 
recupera o último elemento de uma lista, como no exemplo a seguir. 


def listaDinamica = // recuperada de forma dinâmica (ex: de um banco de 
dados) 
def ultimo = listaDinamica.last() 


O método 1ast() não existe em Mapas, estando disponível apenas 
para listas e vetores. 


Técnicas de iteração simples e embarcadas para números, 
coleções e Strings 


É uma tarefa muito comum realizar iterações (repetições) para 
resolver problemas computacionais. Essas iterações são 
comumente baseadas em valores numéricos, nos elementos de 
uma coleção ou nas linhas de um texto. A seguir, veremos como 
essas iterações mais comuns podem ser feitas em Groovy. 


Iteração a partir de números 


Na necessidade da repetição de um trecho de código determinada 
por um número N em Java, é necessário criar estruturas de 
repetição como for , do-while OU while . Em Groovy, os números 
inteiros possuem um recurso embarcado que atende facilmente 
essa necessidade. É a closure timest) . No exemplo a seguir, está 
programada uma repetição de um trecho de código por 11 (onze) 
vezes. 


11.times( 
// o código aqui repetirá 11 vezes 


} 


Em vez do número 11, poderíamos ter aplicado o mesmo recurso 
sobre uma variável do tipo Integer . Caso seja necessário saber em 
que passo da iteração estamos, basta usar a variável it , que é 
injetada automaticamente na Closure times{} . Ela vai de 0 a N-1, 
onde N é o número de iterações. O código do exemplo a seguir 
demonstra como poderíamos lançar mão desse recurso. 


def jogadores = [jogador1, jogador2, jogador3] 

jogadores.size().times{ 
println(jogadores[it].getNome()) 

} 


Por questões de legibilidade de código ou para o caso de iterações 
aninhadas, é possível definir um nome da variável do passo da 
iteração. No exemplo a seguir, usamos o nome j. 


def jogadores = [jogador1, jogador2, jogador3] 

jogadores.size().times( j -> 
println(jogadores[j].getNome()) 

} 


Iteração a partir de List e set 


Quando há repetição de um trecho de código para cada elemento 
de uma coleção em Java, é necessário criar estruturas de repetição 
como for , do-while , while OU usar OS streams OU método forEach() do 
Java 8. Em Groovy, as coleções possuem um recurso embarcado 
que atende facilmente essa necessidade. São as closures eacht) € 
eachWithIndex() , apresentadas e exemplificadas a seguir. No exemplo 
a seguir, está programada uma repetição para os itens de uma List, 
mas que funcionaria da mesma forma para set . O it dentro da 
closure é o nome que cada elemento da lista recebe na iteração. 


def jogadores = [jogador1, jogador2, jogador3] 
jogadores .eachf 
printIn("Nome do Jogador: $(it.getNome())") 


} 


Por questões de legibilidade de código ou para o caso de iterações 
aninhadas, é possível definir um nome do elemento na iteração. No 
exemplo a seguir, usamos o nome jogador . 


def jogadores = [jogador1, jogador2, jogador3] 
jogadores.eachf jogador -> 
printIn("Nome do Jogador: $(jogador.getNome())") 


} 


Caso seja necessário saber em que passo da iteração estamos, 
podemos usar a closure eachwithīIndex . Nesse caso, é obrigatório 
indicar os nomes do elemento e da variável que conterá o índice 
(passo) da iteração (que começa em 0), como demonstrado no 
código do exemplo a seguir, em que chamamos o elemento de 
jogador € O Índice de i. 


def jogadores = [jogador1, jogador2, jogador3] 
jogadores.eachWithIndex{ jogador, i -> 


println("Nome do $(i+1) Jogador: $(jogador.getNome())") 
} 


Iteração a partir de map 


Quando há repetição de um trecho de código para cada elemento 
de um mapa ( map ) em Java, é necessário criar estruturas de 
repetição como for , do-while , while OU usar OS streams OU método 
forEach() do Java 8. Em Groovy, as coleções possuem um recurso 
embarcado que atende facilmente essa necessidade. É a closure 
each{} , apresentada e exemplificada a seguir. 


No exemplo a seguir, está programada uma repetição para os itens 
de um map . O it dentro da closure é o nome que cada elemento do 
Map recebe na iteração. O atributo key, é o chave e O value, O valor 
do elemento. 


def campanha = [derrotas: O, empates: 2, vitorias: 5] 
println("Campanha:") 
campanha.eachf 

println("$(it.key): ${it.value}") // ex de saída: “vitorias: 5" 
} 


Por questões de legibilidade de código ou para o caso de iterações 
aninhadas, é possível definir um nome do elemento na iteração. No 
exemplo a seguir, usamos o nome campanha . 


def campanha = [derrotas: O, empates: 2, vitorias: 5] 
println("Campanha:") 
campanha.eachf campanha -> 

println("$(campanha.key): $(campanha.value)") // ex de saída: 
“vitorias: 5" 


} 


É possível ainda definir diretamente um nome para a chave e outro 
para o valor, como no próximo código, em que os chamamos de 
resultado € quantidade , respectivamente. 


def campanha = [derrotas: ©, empates: 2, vitorias: 5] 
println("Campanha:") 


campanha.eachf resultado, quantidade -> 
println("$fresultado): $(quantidade)") // ex de saída: "vitorias: 5" 


} 
Verificação de "verdadeiro/falso" expandida, porém facilitada 


A verificação de verdadeiro/falso (true/false), provavelmente, a 
mais comum em testes automatizados. É possível fazer esse tipo de 
verificação de forma simplificada em Groovy conforme as situações 
a seguir. 


null é false e não nulo é true 


Qualquer objeto que seja null , quando testado em um assert OU if 
ou operador ternário ou atribuído a uma variável boolean , será 
interpretado como false . Vide o código Groovy de exemplo a seguir, 
cujo assert falharia. 


def jogador = null 
assert jogador 


Nas mesmas situações recém citadas, qualquer objeto não nulo, a 
princípio é true . No código do exemplo a seguir, O assert passaria. 


def jogador = new Futebolista() 
assert jogador 


Observe: foi dito que a princípio, o resultado é true . Existem casos 
em que o objeto não é nulo, mas sua verificação booleana pode ser 
false . Essas exceções serão apresentadas a seguir. 


String Vazia é false e não vazia é true 


Qualquer string que seja vazia ( "" ou '' ), quando testado em um 
assert OU if OU Operador ternário ou atribuído a uma variável boolean 
, Será interpretado como false . Vide o código Groovy de exemplo a 
seguir, cujo assert falharia. 


def nomeNogador = "" 
assert nomeJogador 


Nas mesmas situações recém-citadas, qualquer string não vazia, 
será considerado true . No código do exemplo a seguir, O assert 
passaria. 


def nomeNogador = "Zé Loko" 
assert nomeJogador 


Número 0 (zero) é false . Qualquer outro é true 


Qualquer número, qualquer tipo numérico (inclusive BigDecimal ) que 
seja 0 (zero), quando testado em um assert ou if ou operador 
ternário ou atribuído a uma variável boolean , será interpretado como 
false . Vide o código Groovy de exemplo a seguir, cujos asserts 
falhariam. 


Q 

0.0 

def numeroLoko3 = new BigDecimal(0) 
assert numeroLokol 


def numeroLoko1 


def numeroLoko2 


assert numeroLoko2 
assert numeroLoko3 


Nas mesmas situações recém-citadas, qualquer número diferente 
de zero, mesmo negativo, será considerado true . 


Coleções vazias são false e não vazias São true 


Qualquer coleção ( List , set OU Map ) que seja vazia (sem 
elementos), quando testado em um assert OU if ou operador 
ternário ou atribuído a uma variável boolean , será interpretado como 
false . Vide o código Groovy de exemplo a seguir, cujo assert 
falharia. 


def jogadores = [] 
assert jogadores 


Nas mesmas situações recém-citadas, qualquer coleção não vazia, 
será considerado true . No código do exemplo a seguir, O assert 
passaria. 


def campanha = [derrotas:0, vitorias:7] 
assert campanha 


Métodos embarcados para as conversões mais comuns 


A conversão de tipos é uma operação muito comum nos problemas 
computacionais atuais, principalmente devido à grande quantidade 
de integração de sistemas que ocorre hoje. Em Java, as conversões 
são um tanto verbosas. Em Groovy há métodos de conversão 
embarcados para as conversões mais comuns do cotidiano, como 
exemplificado a seguir. 


Conversão de string para qualquer tipo numérico 


O tipo string em Groovy já possui métodos embarcados para a 
conversão para todos os tipos numéricos da plataforma Java. No 
código de exemplo a seguir, variáveis string são convertidas com 
Sucesso para Integer , Long, BigInteger , Float , Double € BigDecimal. 


def txtNumericoInteiro = '8' 

Integer inteiro = txtNumericoInteiro.toInteger() 

Long longo = txtNumericoInteiro.toLong() 

BigInteger bigInteger = txtNumericoInteiro.toBigInteger() 


def txtNumericoReal = '8.5' 

Float flutuante = txtNumericoReal.toFloat() 

Double duplo = txtNumericoReal.toDouble() 

BigDecimal bigDecimal = txtNumericoReal.toBigDecimal() 


Vale destacar que, caso o valor da string não contenha um número 
válido para a conversão solicitada, uma exceção será lançada. 


Conversão de string para Boolean 


O tipo string em Groovy já possui métodos embarcados para a 
conversão para Boolean . Os valores "true", "y" e "1" são convertidos 
para true . Qualquer outro valor é convertido para false . No código 
do exemplo de conversão a seguir, todas as conversões resultariam 
em true , portanto, todos os assert passariam. 


def textoBoleano = 'true' 
assert textoBoleano.toBoolean() 


textoBoleano = 'y' 
assert textoBoleano.toBoolean() 
textoBoleano = '1' 


assert textoBoleano.toBoolean() 


No código do exemplo de conversão a seguir, todas as conversões 
resultariam em false , portanto, todos os assert falhariam. 


def textoBoleano = 'false' 
assert textoBoleano.toBoolean() 
textoBoleano = 'oi' 

assert textoBoleano.toBoolean() 


textoBoleano = 
assert textoBoleano.toBoolean() 


Manipulação de datas é muito simples 


A manipulação de datas é uma operação muito comum nos 
problemas computacionais atuais. Em Java, as conversões Date para 
String € vice-versa, bem como adicionar ou subtrair dias a datas são 
um tanto verbosas, mesmo na versão 8. Em Groovy há métodos de 
conversão embarcados que facilitam as operações mais comuns 
com datas, como exemplificado a seguir. 


Conversão de string para Date 


Para converter uma string para Date , basta usar o método 
embarcado parse() , informando o formato (pattern) e o texto a ser 
convertido. O código a seguir demonstra como converter um texto 
em data no formato "dd/Mm/yyyy" . 


def txtDataLoka = '01/01/1980' 
def dataLoka = Date.parse('dd/MM/yyyy', txtDataLoka) 


Conversão de pate para string 


Para converter uma Date para string , basta usar o método 
embarcado format () , informando o formato (pattern). O código a 


seguir demonstra como converter uma data em texto no formato 
"dd/MM/yyyy" . 


def agora = new Date() 
def txtAgora = agora.format('dd/MM/yyyy`') 


Adicionando ou subtraindo dias de pate 


Em Groovy, para adicionar ou subtrair dias de uma data pode-se 
simplesmente usar os operadores + e - , literalmente, como é 
exemplificado no código a seguir, que subtrai 1 dia a uma data e 
depois adiciona 2 dias a outra. 


def hoje = new Date() // por exemplo: 02/01/2000 
def ontem = hoje-1 // 01/01/2000 
def amanha = ontem+2 // 03/01/2000 


No código anterior, o objeto hoje não foi alterado. Para que a data 
seja realmente alterada, é preciso, literalmente, substituir seu valor, 
como no exemplo a seguir. 


def dataLoka = new Date() // por exemplo: 02/01/2000 


dataloka = dataLoka-1 // 01/01/2000 
dataLoka = dataLoka+2 // 03/01/2000 
dataLoka++ // 04/01/2000 


Caso o operador - seja aplicado entre datas, o resultado será a 
diferença de dias entre a primeira e a segunda. O código a seguir 
demonstra isso ao comparar a data de hoje com a de amanhã. 


def hoje = new Date() // por exemplo: 01/01/2000 
def amanha = hoje+1  // 02/01/2000 
println(amanha-hoje) // resultado: 1 
println(hoje-amanha) // resultado: -1 


Indo para a zero hora de uma pate 


Em Groovy, é possível ir para a zero hora de uma data usando o 
método embarcado clearTime() . Importante: este método altera a 
data no qual é invocado, não retorna uma versão ajustada para zero 


hora. O exemplo a seguir ajustaria a data na qual foi invocado para 
a zero hora de seu dia. 


def hoje = new Date() // por exemplo: 01/01/2000 15:30:00 
hoje.clearTime() // 01/01/2000 00:00:00 


Acesso direto a métodos privados 


Em Java, um método privado ( private ) não pode ser invocado, a 
não ser com uso da Reflection aPI, O que não é tarefa simples. Em 
Groovy, o acesso a métodos privados é transparente, sendo 
possível invocá-los como se fossem públicos. O código do exemplo 
a seguir é de uma classe Java que possui o método privado 
atualizarClassificacao() , que é invocado por seus outros dois 
métodos que são públicos, O gol() € O finalizar(). 


public class Partida { 
public void gol(Jogador autor) { 
// ações a cada gol... 
this.atualizarClassificacao(); 


public void finalizar() { 
// ações ao finalizar partida 
this.atualizarClassificacao(); 


private void atualizarClassificacao() { 
// ações da atualização da classificação 


} 


Para invocar o método atualizarclassificacao() de uma instância de 
Partida a partir de uma classe Groovy, basta invocá-lo diretamente, 
como se fosse público. O trecho de código Groovy a seguir instancia 
uma Partida € invoca seu método privado. Inclusive as IDEs Eclipse, 
IntelliJ e NetBeans sugerem e aceitam a invocação de métodos 
privados durante a edição de código Groovy. 


def partidaLoka = new Partida(); 
partidaLoka.atualizarClassificacao() 


Esse recurso é muito útil em casos como o do último exemplo, em 
que métodos privados possuem muita relevância, pois permite a 
criação de vários cenários de teste diretamente para eles. 


Alteração do comportamento de métodos em classes e objetos 
em tempo de execução 


Em algumas situações, métodos podem fazer ações muito 
complexas e/ou que dependem de elementos externos. Como 
exemplos temos: acesso a bancos de dados, consumo de APIs e 
uso de bibliotecas de terceiros. Para casos como esse, pode-se 
sobrescrever o comportamento do método em tempo de execução 
em Groovy, sem a necessidade de uma subclasse anônima nem de 
uma instância Mock. 


Tomemos como base a classe a seguir como exemplo, a 
ClienteRestTimesFutebol € seu método getToken() . Esse método 
solicitaria um token de autenticação junto a uma API a partir de um 
usuario € UMa senha. 


public class ClienteRestTimesFutebol { 
public String getToken(String usuario, String senha) { 
// chamada à API para obter 'token' 


} 


No código a seguir, definimos que uma determinada instância de 
ClienteRestTimesFutebol , a que chamamos de clienteLoko passa a ter 
um comportamento diferente para o método getToken() , enquanto a 
instância clientenormal continua com seu método original: 


def clienteLoko = new ClienteRestTimesFutebol() 
clientel.metaClass.getToken = { String u, String s -> 
return "fake-token" 


def clienteNormal = new ClienteRestTimesFutebol() 


def token1 = clienteLoko.getToken(null, null) // apenas retorna "fake- 
token" 

def token2 = clienteNormal.getToken(null, null) // invocaria a versão 
original do "getToken()" 


Caso seja necessário que todos os objetos de uma classe tenham o 
comportamento de um método alterado, é possível fazer esse ajuste 
na classe, consequentemente, em todas as suas instâncias. 
Como no exemplo a seguir, que mudaria O getToken() para qualquer 
instância de clienteRestTimesFutebol : 


ClienteRestTimesFutebol.metaClass.getToken = ( String u, String s -> 
return "fake-token" 


} 
def cliente1 = new ClienteRestTimesFutebol() 


def cliente2 = new ClienteRestTimesFutebol() 


def token1 = cliente1.getToken(null, null) // apenas retorna "fake-token" 
def token2 = cliente2.getToken(null, null) // apenas retorna "fake-token" 


getters e setters podem invocados apenas com o nome do 
atributo 


Os métodos getters € setters fazem parte do dia a dia dos 
desenvolvedores da plataforma Java. Fazem parte do padrão 
JavaBeans 
(https://docs.oracle.com/javase/tutorial/javabeans/writing/properties. 
html) e são usados pelos principais frameworks Java. Seu uso é tão 
comum que as principais IDEs Java possuem assistentes para a 
rápida criação desses métodos. Em Groovy, existe a possibilidade 
invocar esses métodos apenas usando o nome do atributo. 
valorPasse privado, acessível com um get e um set escritos de 
maneira correta: 


public class Futebolista ( 
private double valorPasse; 
public double getValorPasse() { 


return this.valorPasse; 


} 


public void setValorPasse(double valorPasse) { 
this.valorPasse = valorPasse; 


} 
} 


Para acessar OS setValorPasse() € getValorPasse() em uma classe 
Groovy, poderíamos escrever um código como o do exemplo a 
seguir: 


Futebolista jogadorLoko = // obtendo o Futebolista 
jogadorLoko.valorPasse = 50000000 
def passeDoLoko = jogadorLoko.valorPasse 


Apesar de parecer que houve um acesso direto ao atributo, não 
houve. O compilador Groovy verifica se existe um getvalorPasse() na 
segunda linha e se existe um setValorPasse(double parametroo) Na 
terceira. Assim, a versão compilada do último código, para a JVM, 
seria como o código a seguir: 


Futebolista jogadorLoko = // obtendo o Futebolista 
jogadorLoko. setValorPasse(50000000) 
double passeDoLoko = jogadorLoko.getValorPasse() 


Caso o desenvolvedor ache melhor usar OS getters € setters de 
forma explícita em suas classes Groovy, pode fazê-lo sem problema 
algum. 


Conclusão 


Os recursos apresentados neste capítulo são suficientes para o 
leitor iniciante em Groovy, porém existem ainda muito mais recursos 
interessantes nessa linguagem. Se o leitor desejar um guia 
completo, sua documentação oficial (http://groovy- 
lang.org/documentation.html) é muito bem escrita e rica em 
exemplos. 


CAPÍTULO 14 
Apêndice B - Perguntas frequentes sobre o 
Spock framework 


Seguem algumas dúvidas comuns que podem surgir no início dos 
estudos sobre o Spock: 


1. Vou ter que jogar fora todos os testes em JUnit que tenho? 


Não. Seus testes em JUnit continuam funcionando normalmente. 
Você apenas adicionou novas dependências ao projeto para usar 
Spock. 


2. Ainda poderei usar Mockito, PowerMock, TestNG e afins? 


Sim. Seus testes com Mockito, PowerMock, TestNG e afins 
continuam funcionando normalmente e ainda pode usar essas 
bibliotecas em seus testes Spock sempre que achar necessário. 


3. Terei que adotar Groovy no projeto, além dos testes? 


Não. Não precisa adicionar nenhuma linha de código Groovy ao 
resto do seu projeto. Inclusive, as dependências que adicionou 
devido ao Spock podem todas estar apenas no escopo test do 
Maven/Gradle/SBT. 


4. Posso usar o Spock para testar funcionalidades escritas em 
outras linguagens para a JVM como Kotlin, Scala, JRuby e 
Jython? 


Sim. Se todas as dependências estiverem corretas e compatíveis e 
se seu ambiente de desenvolvimento estiver corretamente 
configurado, poderá testar classes escritas em outras linguagens da 
plataforma Java. 


5. Posso escrever testes em projetos Android usando Spock? 
Sim. Basta configurar as dependências no Gradle. 


6. Posso testar códigos escritos em linguagens fora da 
plataforma Java como Python, JavaScript e Go? 


Não. Spock foi feito para testar artefatos da plataforma Java. 
Projetos de outras plataformas de desenvolvimento não podem ser 
testados com ele. 


7. Meus projetos Java 5, 6e 7 são compatíveis com Spock? 


Sim. Este livro tratou do Spock versão 1.1.x que é compatível com 
Java 6 ou superior. A versão 1.2.x não terá compatibilidade com 
Java 6. Existem versões do Spock compatíveis com o Java 5, porém 
nessas versões mais antigas podem não existir várias das 
funcionalidades abordadas neste livro. 


8. O Spock é compatível com Java 9+? 


Até a versão 1.1.x , que foi a abordada nesse livro, não. Porém, 
enquanto esta obra estava sendo escrita, foram liberadas snapshots 
da versão 1.2.x que será compatível. Essa nova versão trará apenas 
sutis diferenças em relação à 1.1.x. 


9. Posso usar o Spock nos meus projetos antigos que não 
usam Maven/Gradle/SBT? 


Sim. Basta seguir o processo de instalação e controle de bibliotecas 
(arquivos .jar ) no classhpath que já usa no projeto. Atente para a 
compatibilidade com a versão do Java usada no projeto (vide 
pergunta 7). 


10. O JaCoCo e plugins de cobertura de testes das IDEs 
Eclipse, IntelliJ e NetBeans são compatíveis com Spock? 


Sim. Os resultados do JaCoCo consideram os testes criados com 
Groovy/Spock, bem como os plugins das principais IDEs da 
plataforma Java. 


11. Groovy tem fama de ser lenta. Spock é lento? 


Mais lento que a testes JUnit escritos em Java, sim. De fato, a 
compilação e a execução de classes Groovy são um pouco mais 
lentas que das escritas em Java. Porém, desde o Java 7 e recursos 
do Groovy 2+ como O compilestatic (http://docs.groovy- 
lang.org/latest/html/gapi/groovy/transform/CompileStatic.html) o 
desempenho de classes Groovy melhorou consideravelmente. A 
diferença de desempenho não leva a outra ordem de grandeza. 
Exemplos: 


e Testes em JUnit que levam poucos segundos para serem 
executados provavelmente levarão também poucos segundos 
em sua execução quando escritos em Spock. 

e Suítes de testes em JUnit que levam pouco menos que 1 
minuto para serem executados provavelmente levarão um 
pouco mais que 1 minuto em sua execução quando escritos em 
Spock. 
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